Re: Which dojo?
Unfortunately, I'm a bit tied up. But i think this is a really really great opportunity for someone who wants to dive into the Web 2.0 javascript technologies and get a handle on how to use it. Not to mention, Dojo is one of the most widespread/popular libraries to be acquainted with. (As noted by there constant development) -Joseph Leong On Wed, Jul 1, 2009 at 12:41 PM, Joseph Leong wrote: > So unfortunately what happened between Dojo 0.4.3-> Mostly anything newer > especially 1.3.1 is that they had the idea to classify their libraries to > "Dijit" (Widgets) and other subsections. As such, the porting effort is not > small. I believe the debug-views portlets and such still depend on 0.4.3. At > this point in time, my opinion would be to not try and migrate any 0.4.3 > dependent code. There has been so much change between the dojo versions that > it would be probably simpler and cleaner to just rewrite these portlets. I > think it'd be a good choice to get rid of the old Dojo libraries once and > for all as they add a bit to the geronimo footprint size.. not to mention > there are a lot more features in the latest Dojo release that can probably > accomplish what you wanted to in the older versions. > > Thanks, > Joseph Leong > > > On Wed, Jul 1, 2009 at 12:10 PM, David Jencks wrote: > >> >> On Jul 1, 2009, at 1:14 AM, Ivan wrote: >> >> I think the one is what need, no samples and testcases are included. But I >> found 1.3.1 is released, why not use the newest one ? >> >> >> Newer would be better if we can get it to work. I set this up a few days >> ago and forgot the details... I think that I saw some problem and wasn't >> sure what was causing it and tried changing to an earlier dojo version. I >> didn't actually have any reason to think the problem was caused by dojo so >> very likely the more recent release should work. >> >> And for the legacy dojo 0.4.3, how shall we handle it ? Like tomcat, >> maitaine a our own repo ? >> >> >> Ideally I think we would migrate our code to up-to-date dojo. >> Unfortunately I have no idea how hard that would be. Does anyone? If we >> can't, I think there is some release of some 0.4.3 dojo, perhaps we can >> investigate using or repackaging it. >> >> There's also dwr but I think working on one dependency at a time will >> be less confusing. >> >> thanks >> david jencks >> >> >> >> 2009/7/1 David Jencks >> >>> In my attempt to remove our svn repo I found that dojo releases a >>> dojo-war that looks pretty similar to our repacked dojo war. I can make the >>> build work with the substitution but I don't know enough about dojo to know >>> if/what it breaks. Is there anyone who understands our use of dojo well >>> enough to take a look and see if this replacement is plausible? >>> >>> I recall some discussion in the distant past about not including all of >>> dojo... I'm not sure if this is still a concern, but if the released >>> dojo-war works and is too big we can use maven to come up with a smaller >>> war. >>> >>> See https://issues.apache.org/jira/browse/GERONIMO-4723 for my patch. >>> >>> thanks >>> david jencks >>> >> >> >> >> -- >> Ivan >> >> >> >
Re: Which dojo?
So unfortunately what happened between Dojo 0.4.3-> Mostly anything newer especially 1.3.1 is that they had the idea to classify their libraries to "Dijit" (Widgets) and other subsections. As such, the porting effort is not small. I believe the debug-views portlets and such still depend on 0.4.3. At this point in time, my opinion would be to not try and migrate any 0.4.3 dependent code. There has been so much change between the dojo versions that it would be probably simpler and cleaner to just rewrite these portlets. I think it'd be a good choice to get rid of the old Dojo libraries once and for all as they add a bit to the geronimo footprint size.. not to mention there are a lot more features in the latest Dojo release that can probably accomplish what you wanted to in the older versions. Thanks, Joseph Leong On Wed, Jul 1, 2009 at 12:10 PM, David Jencks wrote: > > On Jul 1, 2009, at 1:14 AM, Ivan wrote: > > I think the one is what need, no samples and testcases are included. But I > found 1.3.1 is released, why not use the newest one ? > > > Newer would be better if we can get it to work. I set this up a few days > ago and forgot the details... I think that I saw some problem and wasn't > sure what was causing it and tried changing to an earlier dojo version. I > didn't actually have any reason to think the problem was caused by dojo so > very likely the more recent release should work. > > And for the legacy dojo 0.4.3, how shall we handle it ? Like tomcat, > maitaine a our own repo ? > > > Ideally I think we would migrate our code to up-to-date dojo. > Unfortunately I have no idea how hard that would be. Does anyone? If we > can't, I think there is some release of some 0.4.3 dojo, perhaps we can > investigate using or repackaging it. > > There's also dwr but I think working on one dependency at a time will > be less confusing. > > thanks > david jencks > > > > 2009/7/1 David Jencks > >> In my attempt to remove our svn repo I found that dojo releases a dojo-war >> that looks pretty similar to our repacked dojo war. I can make the build >> work with the substitution but I don't know enough about dojo to know >> if/what it breaks. Is there anyone who understands our use of dojo well >> enough to take a look and see if this replacement is plausible? >> >> I recall some discussion in the distant past about not including all of >> dojo... I'm not sure if this is still a concern, but if the released >> dojo-war works and is too big we can use maven to come up with a smaller >> war. >> >> See https://issues.apache.org/jira/browse/GERONIMO-4723 for my patch. >> >> thanks >> david jencks >> > > > > -- > Ivan > > >
[jira] Updated: (GERONIMO-4254) RSS 2.0 Feed Reader For AG and Misc Feeds in Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-4254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-4254: --- Attachment: htdocs.rar The demonstration can be found at the index.html > RSS 2.0 Feed Reader For AG and Misc Feeds in Admin Console > -- > > Key: GERONIMO-4254 > URL: https://issues.apache.org/jira/browse/GERONIMO-4254 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Reporter: Joseph Leong > Assignee: Joseph Leong >Priority: Minor > Attachments: htdocs.rar > > > So i've been working on a lightweight javascript RSS reader that we might > find useful to implement in the admin console. Users might find this RSS > reader useful to viewing an AG syndicated feed should the community decide to > start one. The RSS feed reader currently uses DojoX's scrollpane in > conjunction with TitlePanes. This is just a first time implementation and i > plan to figure a way to reduce it's size so it doesn't take up much screen > real estate. Current existing problems is that javascript is client side so > the reader can't go out and fetch external RSS files. Any input on a good > way to accomplish this in a light weight fashion would be appreciated, > otherwise i'll be trying to wrap this in a portlet to 'GET' the rss files. > Make note of the different local feeds available and the possibility of > highlighting certain feeds depending on the category classification. > -Joseph Leong -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4254) RSS 2.0 Feed Reader For AG and Misc Feeds in Admin Console
[ https://issues.apache.org/jira/browse/GERONIMO-4254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623796#action_12623796 ] Joseph Leong commented on GERONIMO-4254: This rar includes dojo 1.1.1 > RSS 2.0 Feed Reader For AG and Misc Feeds in Admin Console > -- > > Key: GERONIMO-4254 > URL: https://issues.apache.org/jira/browse/GERONIMO-4254 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Attachments: htdocs.rar > > > So i've been working on a lightweight javascript RSS reader that we might > find useful to implement in the admin console. Users might find this RSS > reader useful to viewing an AG syndicated feed should the community decide to > start one. The RSS feed reader currently uses DojoX's scrollpane in > conjunction with TitlePanes. This is just a first time implementation and i > plan to figure a way to reduce it's size so it doesn't take up much screen > real estate. Current existing problems is that javascript is client side so > the reader can't go out and fetch external RSS files. Any input on a good > way to accomplish this in a light weight fashion would be appreciated, > otherwise i'll be trying to wrap this in a portlet to 'GET' the rss files. > Make note of the different local feeds available and the possibility of > highlighting certain feeds depending on the category classification. > -Joseph Leong -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4254) RSS 2.0 Feed Reader For AG and Misc Feeds in Admin Console
RSS 2.0 Feed Reader For AG and Misc Feeds in Admin Console -- Key: GERONIMO-4254 URL: https://issues.apache.org/jira/browse/GERONIMO-4254 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor So i've been working on a lightweight javascript RSS reader that we might find useful to implement in the admin console. Users might find this RSS reader useful to viewing an AG syndicated feed should the community decide to start one. The RSS feed reader currently uses DojoX's scrollpane in conjunction with TitlePanes. This is just a first time implementation and i plan to figure a way to reduce it's size so it doesn't take up much screen real estate. Current existing problems is that javascript is client side so the reader can't go out and fetch external RSS files. Any input on a good way to accomplish this in a light weight fashion would be appreciated, otherwise i'll be trying to wrap this in a portlet to 'GET' the rss files. Make note of the different local feeds available and the possibility of highlighting certain feeds depending on the category classification. -Joseph Leong -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Reducing the dojo footprint in Geronimo
Kevan, I am far from having the complete picture, but my understanding for #3: According to a post from Donald previously, this link is very good reference for what process is involved: http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds, in creating our slim 'mydojo.js'. As for the maintenance, i see the scenarios where every app using dojo will now need to cross reference with what is available in mydojo.js to see if the feature they want to use is already included. If not we'll have to re-generate a new slim version of our 'mydojo.js' with the features added. Furthermore, when an app becomes obsolete or is removed, we will need to regenerate a new mydojo.js to remove the unnecessary components. On the user level, I also see some inefficiency where if one wants to deploy a product on AG that uses some dojo subsets which is not in our generated mydojo.js, they'd have to include their own copy of dojo. -Joseph Leong On Wed, Jul 30, 2008 at 10:59 AM, Kevan Miller <[EMAIL PROTECTED]>wrote: > > On Jul 29, 2008, at 3:36 PM, Joseph Leong wrote: > > Hi everyone, > > So i'm building a little widget piece to run on AG and i've come to the > point of deciding whether i'm going to incorporate any (if) dojo/dojox > components into it. I know we've had varying discussions about reducing the > dojo footprint. To summarize i believe the only thing we've agreed on so > far is removing the unncessary /tests , but i'm wondering if the community > had anymore input on keeping dojox around? To summarize it is my > understanding these are the choices suggested so far: > > 1) Removing Dojo from AG and having users include their own optimized Dojo > files for their apps. The downside is that we may be inefficient in > aggregating multiple copies of Dojo. > > 2) Leave Dojo support in AG as is now. We can safely rely on the fact that > their will be no duplicate instances of dojo for those who use it, but we > must now rely on having that dojo overhead even for users who don't utilize > it. > > 3) Creating a slim version of Dojo to support the features relying on it in > AG, thus allowing users who want to demonstrate fundamental dojo features to > utilize it - but however we incur the maintenance overhead of creating new > builds of Dojo to incorporate with AG releases as new fundamental AG > components with Dojo are included. > > Personally, I feel the functionality subset of DojoX captures a lot of what > this Web2.0 era is looking for. Although it may make more sense to go with > option 3, now, i feel it's only a matter of time before we switch over to > option 2. To provide the community with a better grasp of what the DojoX > functionalities are goto: http://dojocampus.org/explorer/#Dojox and you'll > find yourself quite surprised at how innovative and integrated these > technologies are influencing your favorite sites. > > > Thanks a lot for picking this up, again, Joseph. > > Personally, I'd like to see the Dojo footprint within Geronimo reduced. > It's pretty simple to make a full-Dojo plugin that users can install, if > they want a full Dojo library available. IMO, this can meet the needs of > Dojo users (as described in #2). > > Can you help me understand the maintenance overhead of creating a > customized Dojo library? If #3 is high maintenance, I may need to > reconsider. > > --kevan > >
Re: Reducing the dojo footprint in Geronimo
Hi everyone, So i'm building a little widget piece to run on AG and i've come to the point of deciding whether i'm going to incorporate any (if) dojo/dojox components into it. I know we've had varying discussions about reducing the dojo footprint. To summarize i believe the only thing we've agreed on so far is removing the unncessary /tests , but i'm wondering if the community had anymore input on keeping dojox around? To summarize it is my understanding these are the choices suggested so far: 1) Removing Dojo from AG and having users include their own optimized Dojo files for their apps. The downside is that we may be inefficient in aggregating multiple copies of Dojo. 2) Leave Dojo support in AG as is now. We can safely rely on the fact that their will be no duplicate instances of dojo for those who use it, but we must now rely on having that dojo overhead even for users who don't utilize it. 3) Creating a slim version of Dojo to support the features relying on it in AG, thus allowing users who want to demonstrate fundamental dojo features to utilize it - but however we incur the maintenance overhead of creating new builds of Dojo to incorporate with AG releases as new fundamental AG components with Dojo are included. Personally, I feel the functionality subset of DojoX captures a lot of what this Web2.0 era is looking for. Although it may make more sense to go with option 3, now, i feel it's only a matter of time before we switch over to option 2. To provide the community with a better grasp of what the DojoX functionalities are goto: http://dojocampus.org/explorer/#Dojox and you'll find yourself quite surprised at how innovative and integrated these technologies are influencing your favorite sites. Thanks, -Joseph Leong On Mon, Jun 30, 2008 at 7:29 AM, Shiva Kumar H R <[EMAIL PROTECTED]> wrote: > > > On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > >> Sounds like the right solution, given that would allow our console to >> upgrade at a slower pace and would allow users to choose their own level... >> >> Other option, is to drop the /dojo webapp in 2.2, only ship what we need >> in the console and let users package the Dojo level and features they need >> within their own apps (which is more portable across different servers >> anyway) >> > > On http://cwiki.apache.org/GMOxDEV/using-dojo-in-geronimo.html we say: > > "AJAX developers usually incorporate the Dojo library into their > applications by making a copy of its static files (javascript, css, gifs, > etc) in their webapp and referencing those files from their servlets and > JSPs. The downside of this approach is that each application has a separate > copy of the AJAX library, increasing the server's overall footprint and > preventing browsers from using a single copy of the library files from their > caches. Another downside is that the AJAX library can't be upgraded or > otherwise managed independently from the web applications that contain it. > For example, a web application deployed across a cluster might need to serve > up the static Dojo files from a central location. Hosting the Dojo files in > a separate webapp can help work around these problems." > > So asking users to package the Dojo level and features they need within > their own apps would imply the downsides mentioned above. Providing an > installable dojo plugin that's equivalent to the /dojo support we currently > provide as suggested by Kevan seems to be an excellent alternative. > > -Donald >> >> >> >> Kevan Miller wrote: >> >>> >>> On Jun 27, 2008, at 11:00 AM, Shrey Banga wrote: >>> >>> >>>> As for the including the rest of DojoX, since it a significant part of >>>> the reducing effort. Would it make sense to build a custom js for >>>> monitoring, remove the rest of DojoX and if the development starts shifting >>>> to a real need for DojoX to make a decision to bring it back in the future? >>>> >>>> I think that makes perfect sense- not only will this do the part in >>>> reducing the dojo footprint, it'll also be useful as an example to how dojo >>>> should be used optimally in deployment. Another desirable side-effect would >>>> be reduced load times in the monitoring application, although currently >>>> that >>>> is not an issue. >>>> >>> >>> I'm starting to think that our server should deliver dojo support that is >>> targeted to the requirements of the admin console. >>> >>> For general dojo support, we could provide an installable dojo plugin >>> that's equivalent to the /dojo support we currently provide... >>> >>> --kevan >>> >>> > > > -- > Thanks, > Shiva
[jira] Commented: (GERONIMO-3599) Unable to create new JMS Resource group through console in IE7
[ https://issues.apache.org/jira/browse/GERONIMO-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614388#action_12614388 ] Joseph Leong commented on GERONIMO-3599: Continually working on this hoping to contribute for release. Have been trying to convert everything over to sessions. A little frustrating, taking some time converting to storing in session as well as recalling data from a session. Also, trying to figure out and figuring out where the lose ends are. -Joseph Leong > Unable to create new JMS Resource group through console in IE7 > -- > > Key: GERONIMO-3599 > URL: https://issues.apache.org/jira/browse/GERONIMO-3599 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0.1 > Environment: WIN XP >Reporter: Anish Pathadan >Assignee: Joseph Leong > Fix For: 2.1.2, 2.1.x, 2.2 > > > I am not able to create a new JMS Resouce group through console. I am getting > cannot display the page error after entering the Q name and physical name and > then pressing next. > The following is the url > http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1 > The problem only comes with Internet Explorer 7. > Best Regards, > Anish Pathadan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Welcome Shiva Kumar H R as the newest member of the Geronimo PMC
Shiva Congrats!!! Keep up the hard work! -Joseph Leong On Mon, Jul 7, 2008 at 9:02 AM, Shiva Kumar H R <[EMAIL PROTECTED]> wrote: > Thanks :) > > > On Mon, Jul 7, 2008 at 6:16 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]> > wrote: > >> Further to my last note... there were no objections from the board on >> Shiva's inclusion in Geronimo PMC. Shiva is officially a PMC member from >> 26th Jun 2008 onwards. >> >> Sorry for the mess. Congratulations Shiva and thanks for your patience >> :o). >> >> ++Vamsi >> >> >> On Mon, Jun 23, 2008 at 6:42 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]> >> wrote: >> >>> My apologies to Shiva for making the announcement without letting the 72 >>> hour waiting period elapse after the ASF Board acknowledged voting Shiva in >>> by the PMC. As of now, Shiva is not a PMC member and will become one once >>> there are no objections by the board in that waiting period. I will >>> announce then. I am withdrawing this announcement (if there is such a >>> provision!!). >>> >>> ++Vamsi >>> >>> On Mon, Jun 23, 2008 at 5:13 PM, Vamsavardhana Reddy < >>> [EMAIL PROTECTED]> wrote: >>> >>>> All, >>>> Please join us in congratulating Shiva Kumar H R as the newest member of >>>> the Geronimo PMC. It's been great to have Shiva working with us as a >>>> committer on Geronimo. Even better to have him join us in providing >>>> oversight of the Geronimo project. >>>> >>>> Way to go Shiva!!! >>>> >>>> The Apache Geronimo PMC >>>> >>>> ++Vamsi >>>> >>> >>> >> > > > -- > Thanks, > Shiva
Re: Geronimo v2.2 discussion
I'm working on having the debug-views fully converted for dojo 1.1.1 purposes. -Joseph Leong On Thu, Jul 3, 2008 at 11:04 AM, Hernan Cunico <[EMAIL PROTECTED]> wrote: > Donald Woods wrote: > >> Shouldn't we put roadmap/release/project management type info in the >> GMOxPMT space instead? The DEV space is getting crowded with other topics >> and it's hard to find the Roadmap pages >> >> >> -Donald >> >> >> Hernan Cunico wrote: >> >>> Hi All, >>> We kinda started to have some discussion some time ago but couldn't find >>> any hit on nabble so not sure were we left it. >>> >>> I added a Geronimo v2.2 Roadmap <../GMOxDEV/geronimo-v22-roadmap.html> >>> page at the top of the Development section in the wiki front page, >>> http://cwiki.apache.org/geronimo/ so we can resume the discussion and >>> collect all our thoughts in one place. (edit access is limited to >>> committers/contributors though) >>> >>> Does anybody already have a list? >>> >>> Cheers! >>> Hernan >>> >>> OK, it's now moved to GMOxPMGT and renamed it to Geronimo 2.2 Release > Plan <http://cwiki.apache.org/GMOxPMGT/geronimo-22-release-plan.html> > > Cheers! > Hernan >
Re: Using GEP with AG Trunk (2.2) ?
Hi Tim, I incredibly appreciate it! Thanks for the hard work. -Joseph Leong On Wed, Jul 2, 2008 at 5:07 PM, Tim McConnell <[EMAIL PROTECTED]> wrote: > Hi Joe, I know exactly the problem you're having. I opened a JIRA to > address this problem some time back, but haven't gotten around to fix it. > I'll work on it later tonight -- should be fairly simple to fix > > -> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-332 > > > Joseph Leong wrote: > >> Hi Everyone, >> >> I'm doing some plugin development.. what better i thought that GEP! So >> here lies the problem.. >> >> I was wondering if anyone has had any success with using the GEP 2.1.2 on >> a copy of AG Trunk? I'm at a point where it says that it detects the 2.2 >> Snapshot but that it was expecting 2.1. And anyway i slice it, i can't seem >> find a proper way of making it fit. Am i missing something obvious? >> >> Thanks! >> >> -Joseph Leong >> > > -- > Thanks, > Tim McConnell >
Using GEP with AG Trunk (2.2) ?
Hi Everyone, I'm doing some plugin development.. what better i thought that GEP! So here lies the problem.. I was wondering if anyone has had any success with using the GEP 2.1.2 on a copy of AG Trunk? I'm at a point where it says that it detects the 2.2 Snapshot but that it was expecting 2.1. And anyway i slice it, i can't seem find a proper way of making it fit. Am i missing something obvious? Thanks! -Joseph Leong
Re: Quick development of jsp pages in Admin Console
Hi Shrey, I'll be more than glad to document it for you. -Joseph Leong On Wed, Jul 2, 2008 at 6:09 AM, Shrey Banga <[EMAIL PROTECTED]> wrote: > Hi, > > I was trying to edit this page- > http://cwiki.apache.org/GMOxDEV/building-apache-geronimo.html but it says > I do not have permission to edit it. Also, I experimented a little with > inPlace deployment but couldn't get it to work for plancreator and I think > the method described above is useful for admin console webapps. Can someone > else document this method ? > > > On Mon, Jun 30, 2008 at 9:03 PM, Hernan Cunico <[EMAIL PROTECTED]> wrote: > >> Kevan Miller wrote: >> >>> >>> On Jun 30, 2008, at 8:43 AM, Shrey Banga wrote: >>> >>> Hi, >>>> >>>> While working on PlanCreator, I initially restarted it after each >>>> modification to the code which is too cumbersome for testing small changes >>>> especially in the JSPs. Thanks to Manu, I realized that there's an easier >>>> workaround to this:- >>>> >>>> 1. Modify \var\catalina\conf\web.xml: >>>> * Set the *development* parameter to *true* in the >>>>init-param to org.apache.jasper.servlet.JspServlet >>>> * Edit (add if doesn't exist) the >>>>*modificationTestInterval* to *0* >>>> 2. In the webapp that you intend to modify, find the web.xml and >>>> remove the servlet-name and servlet-mapping of the jsp you >>>> intend to modify and test. >>>> For example, for PlanCreator I edit the >>>> plancreator-console-tomcat-2.2-SNAPSHOT.car\WEB-INF\web.xml. >>>> 3. Restart the server with these settings in place. >>>> >>>> Once this is done, you can modify the jsp in place and hit refresh to >>>> test it. It'll be recompiled each time. I think this is very handy for >>>> developing and testing deployed web applications. Can someone copy this to >>>> wiki or grant me access to it ? >>>> >>> >>> Looks like Shrey has already submitted an ICLA to the ASF. Hernan, can >>> you give Shrey access? >>> >>> --kevan >>> >> My machine got toasted (literally) last week and I'm still struggling with >> the new one. >> >> I just added Shrey to geronimo-contributors. >> >> for the record, any confluence admin can do this, a list with the admins >> is available at >> http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html >> >> Shrey, let us know if you have any questions >> >> btw, wouldn't a scenario like the one described be addressed by inPlace >> deployment ? I used that in the past and worked like a charm >> >> btw 2, Firefox 3 is also giving me headaches. >> >> Cheers! >> Hernan >> > > > > -- > Shrey Banga > Bachelor of Technology, III year > Department of Electrical Engineering > Indian Institute of Technology Roorkee >
Re: Quick development of jsp pages in Admin Console
Shrey, I think this is a great idea! This will substantially help increase frontend development, as i've been applying things with the longer method so far. Also i believe there might be some method with in-place deployment as well - i'll take a look and see if i can find anything to add about that. -Joseph Leong
Re: Reducing the dojo footprint in Geronimo
I agree with you Jason and I feel 'experimental' can be casted in different light. Looking at it's function exclusively, it seems to be fitting our needs and is stable from what i can see. Having said that, i agree with your approach Shrey - The part where you mentioned the ability to create a custom js for the specific functionality of the monitoring console that required particular dojox dependencies. So that would give us the slimmest version of what we want from DojoX and allow us to remove the rest. As for the including the rest of DojoX, since it a significant part of the reducing effort. Would it make sense to build a custom js for monitoring, remove the rest of DojoX and if the development starts shifting to a real need for DojoX to make a decision to bring it back in the future? As pointed out, a lot of the functionality can be and was intended to be completed with dijit and dojo. Thoughts? -Joseph Leong On Fri, Jun 27, 2008 at 8:58 AM, Shrey Banga <[EMAIL PROTECTED]> wrote: > Donald, > > Are you suggesting we build all of the dojo, dijit and dojox scripts into > one single js and use that? I think that will be highly inexpedient. > For one, running the builder for all possible scripts in dojo is both > extremely tedious as the builder requires that we provide the basic modules > that our webapp needs, similar to dojo.requires in the webpages. In this > case, we'll have to require all the modules to be sure that none are left. > Even if we manage to do that, what we'll get is a massive js that will kill > most, if not all, webapps. What I'm suggesting is to build the specific > modules required by the Monitor application into one js and include that > within the application instead of using the dojo files in the repository. > Then we can get rid of dojox and advise users to do the same. > > > On Fri, Jun 27, 2008 at 6:10 PM, Donald Woods <[EMAIL PROTECTED]> wrote: > >> Then why not keep the dojox and just rebuild everything (minnus the demo >> and test files) into a single .js for the Dojo Plugin? >> >> I really don't want 2 copies of this in the server, which would be worse >> than 1 larger copy >> >> >> -Donald >> >> >> Shrey Banga wrote: >> >>> Dojo does have a builder which can parse the dojo tree to create a single >>> .js that is compressed and can be included with the webapp. Although this is >>> intended for the purpose of speeding up webpages and avoiding lock up of >>> resources while all the js is loaded, it can be used similarly for the >>> purpose of the monitor console so that dojox can be removed from the >>> repository and the .js that has been built can be included with the monitor. >>> I think this would be a better approach than manually fishing out the >>> required js. This should be the approach any geronimo user intending to use >>> dojox features should use as they are bound to change in further releases. >>> As Lin Sun pointed out, we shouldn't really be using the experimental >>> features anyway. As and when these features are accommodated in the >>> dojo/dijit components we can include them too. >>> >>> On Fri, Jun 27, 2008 at 2:29 AM, Lin Sun <[EMAIL PROTECTED] >> [EMAIL PROTECTED]>> wrote: >>> >>>Would it be possible that we release the monitor console piece as an >>>external plugin where users can install it on demand? That way, >>>whoever wants to see the monitor console piece can install it along >>>with the dojox dependency and we don't need to figure out/bundle which >>>pieces of dojox we need.Also, I am a bit surprised that we are >>>using dojox as that is supposed to be incubator phase for dojo. >>> >>>Lin >>> >>> >>> >>> >>> -- >>> Shrey Banga >>> Bachelor of Technology, III year >>> Department of Electrical Engineering >>> Indian Institute of Technology Roorkee >>> >> > > > -- > Shrey Banga > Bachelor of Technology, III year > Department of Electrical Engineering > Indian Institute of Technology Roorkee >
Re: Reducing the dojo footprint in Geronimo
Actually thinking about this further, i'm not so sure stripping out DojoX would be a good idea. DojoX has a lot features, and i realize we aren't using them now. But thinking about it the process of stripping down DojoX to just the components in Monitoring might be a maintenance nightmare. Taking a deeper look, there are a lot of dependencies and trails that you have to follow in the js files to completely separate out functioning pieces of dojox. In addition, if anyone were to add a another dojox feature, we'd have to follow suite with stripping out that component exclusively to achieve a small package size. Thoughts? -Joseph Leong On Thu, Jun 26, 2008 at 3:18 PM, Joseph Leong <[EMAIL PROTECTED]> wrote: > Jason, > > I agree with that approach. The widget and other components are the > mainstream features. In efforts to reducing the size and to support the > monitoring features , i don't see why not just leave the charting features. > Does anyone else see a problem with this? > > -Joseph Leong > > > On Thu, Jun 26, 2008 at 3:09 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > >> Joe, >> >> Is it possible to pull in just the dojox charting features? I think the >> main driving factor of this is to drop dojox as that is 80% of the weight >> that would be dropped. If we can't keep just the charting features, then >> we're going to have to keep all of dojox or change how the monitoring plugin >> draws the graphs (I assume that's what it's used for). >> >> On Thu, Jun 26, 2008 at 2:33 PM, Joseph Leong <[EMAIL PROTECTED]> >> wrote: >> >>> Hi Shrey, >>> >>> I think that makes a lot of sense, especially with the tests and demos. >>> My only comment is i believe the monitoring plugin may use some of the DojoX >>> charting features. However, after doing some research with dojo and AG >>> regarding the 0.4->1.1.1 conversion i think that was the only plugin with >>> dojox issues. Other than that, great idea on reducing the dojo footprint. >>> >>> -Joseph Leong >>> >>> >>> On Thu, Jun 26, 2008 at 12:49 PM, Lin Sun <[EMAIL PROTECTED]> wrote: >>> >>>> Hi, what you propose makes sense to me. Can you suggest the best way >>>> to achieve this, possibly in a JIRA with a patch? >>>> >>>> Thanks, Lin >>>> >>>> On 6/26/08, Shrey Banga <[EMAIL PROTECTED]> wrote: >>>> > Hi all, >>>> > >>>> > I've been working on the EAR PlanCreator and I've observed that dojo >>>> is >>>> > shipped with all the demos, tests and experimental widgets in place, >>>> causing >>>> > the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). >>>> > Looking at the various folders, I think we can achieve significant >>>> > reduction in the dojo footprint and eventually of the server itself by >>>> > removing the following components: >>>> > dojo/tests - 579 KB >>>> > dijit/tests - 551 KB >>>> > dijit/demos - 909 KB >>>> > dojox - 6.82 MB >>>> > >>>> > From a geronimo user's perspective, the tests suite is not of much use >>>> as >>>> > they are meant to test the widgets provided by dojo itself which can >>>> be >>>> > tested by separately downloading the given release instead of shipping >>>> it >>>> > with the server. Similarly, the demos, which are used to exhibit >>>> dojo's >>>> > capabilities, can be run directly from dojo's website or downloaded >>>> and run >>>> > locally without the server. Also, people trying to learn from the >>>> demos tend >>>> > to use the css provided for the purpose of the demo, which is not >>>> > recommended. >>>> > My rationale for removing the dojox is that these are marked as >>>> > experimental by the dojo community and although some components are >>>> used >>>> > often, keeping 6.8 MBs of code that is still experimental does not >>>> make >>>> > sense. It is better to trust the dojo community to shift components >>>> from >>>> > experimental to stable areas and then use them in further releases. >>>> > >>>> > Removing the stated components frees up about 8.7 MBs of space on the >>>> > expanded server, which is huge for a javascript library. Since a >>>> Geronimo >>>> > user can still include these components into his/her webapp we're not >>>> really >>>> > stopping them from using these components, only transferring the >>>> overhead of >>>> > using the lesser used components onto the user. >>>> > -- >>>> > Shrey Banga >>>> > Bachelor of Technology, III year >>>> > Department of Electrical Engineering >>>> > Indian Institute of Technology Roorkee >>>> >>> >>> >> >> >> -- >> ~Jason Warner > > >
Re: Reducing the dojo footprint in Geronimo
Jason, I agree with that approach. The widget and other components are the mainstream features. In efforts to reducing the size and to support the monitoring features , i don't see why not just leave the charting features. Does anyone else see a problem with this? -Joseph Leong On Thu, Jun 26, 2008 at 3:09 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > Joe, > > Is it possible to pull in just the dojox charting features? I think the > main driving factor of this is to drop dojox as that is 80% of the weight > that would be dropped. If we can't keep just the charting features, then > we're going to have to keep all of dojox or change how the monitoring plugin > draws the graphs (I assume that's what it's used for). > > On Thu, Jun 26, 2008 at 2:33 PM, Joseph Leong <[EMAIL PROTECTED]> > wrote: > >> Hi Shrey, >> >> I think that makes a lot of sense, especially with the tests and demos. >> My only comment is i believe the monitoring plugin may use some of the DojoX >> charting features. However, after doing some research with dojo and AG >> regarding the 0.4->1.1.1 conversion i think that was the only plugin with >> dojox issues. Other than that, great idea on reducing the dojo footprint. >> >> -Joseph Leong >> >> >> On Thu, Jun 26, 2008 at 12:49 PM, Lin Sun <[EMAIL PROTECTED]> wrote: >> >>> Hi, what you propose makes sense to me. Can you suggest the best way >>> to achieve this, possibly in a JIRA with a patch? >>> >>> Thanks, Lin >>> >>> On 6/26/08, Shrey Banga <[EMAIL PROTECTED]> wrote: >>> > Hi all, >>> > >>> > I've been working on the EAR PlanCreator and I've observed that dojo is >>> > shipped with all the demos, tests and experimental widgets in place, >>> causing >>> > the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). >>> > Looking at the various folders, I think we can achieve significant >>> > reduction in the dojo footprint and eventually of the server itself by >>> > removing the following components: >>> > dojo/tests - 579 KB >>> > dijit/tests - 551 KB >>> > dijit/demos - 909 KB >>> > dojox - 6.82 MB >>> > >>> > From a geronimo user's perspective, the tests suite is not of much use >>> as >>> > they are meant to test the widgets provided by dojo itself which can be >>> > tested by separately downloading the given release instead of shipping >>> it >>> > with the server. Similarly, the demos, which are used to exhibit dojo's >>> > capabilities, can be run directly from dojo's website or downloaded and >>> run >>> > locally without the server. Also, people trying to learn from the demos >>> tend >>> > to use the css provided for the purpose of the demo, which is not >>> > recommended. >>> > My rationale for removing the dojox is that these are marked as >>> > experimental by the dojo community and although some components are >>> used >>> > often, keeping 6.8 MBs of code that is still experimental does not make >>> > sense. It is better to trust the dojo community to shift components >>> from >>> > experimental to stable areas and then use them in further releases. >>> > >>> > Removing the stated components frees up about 8.7 MBs of space on the >>> > expanded server, which is huge for a javascript library. Since a >>> Geronimo >>> > user can still include these components into his/her webapp we're not >>> really >>> > stopping them from using these components, only transferring the >>> overhead of >>> > using the lesser used components onto the user. >>> > -- >>> > Shrey Banga >>> > Bachelor of Technology, III year >>> > Department of Electrical Engineering >>> > Indian Institute of Technology Roorkee >>> >> >> > > > -- > ~Jason Warner
[jira] Closed: (GERONIMO-4158) Plan Creator attempts to load old widget files after dijit migration
[ https://issues.apache.org/jira/browse/GERONIMO-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong closed GERONIMO-4158. -- Resolution: Fixed > Plan Creator attempts to load old widget files after dijit migration > > > Key: GERONIMO-4158 > URL: https://issues.apache.org/jira/browse/GERONIMO-4158 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: PlanCreator >Affects Versions: 2.2 > Environment: Ubuntu 7.10, Firefox >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Trivial > Fix For: 2.2 > > > The plancreator-portlets has some leftover code that allocates resources for > loading the old widget system which will soon be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Reducing the dojo footprint in Geronimo
Hi Shrey, I think that makes a lot of sense, especially with the tests and demos. My only comment is i believe the monitoring plugin may use some of the DojoX charting features. However, after doing some research with dojo and AG regarding the 0.4->1.1.1 conversion i think that was the only plugin with dojox issues. Other than that, great idea on reducing the dojo footprint. -Joseph Leong On Thu, Jun 26, 2008 at 12:49 PM, Lin Sun <[EMAIL PROTECTED]> wrote: > Hi, what you propose makes sense to me. Can you suggest the best way > to achieve this, possibly in a JIRA with a patch? > > Thanks, Lin > > On 6/26/08, Shrey Banga <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I've been working on the EAR PlanCreator and I've observed that dojo is > > shipped with all the demos, tests and experimental widgets in place, > causing > > the folder to be about 12.8 MB on the expanded server (2.2-SNAPSHOT). > > Looking at the various folders, I think we can achieve significant > > reduction in the dojo footprint and eventually of the server itself by > > removing the following components: > > dojo/tests - 579 KB > > dijit/tests - 551 KB > > dijit/demos - 909 KB > > dojox - 6.82 MB > > > > From a geronimo user's perspective, the tests suite is not of much use as > > they are meant to test the widgets provided by dojo itself which can be > > tested by separately downloading the given release instead of shipping it > > with the server. Similarly, the demos, which are used to exhibit dojo's > > capabilities, can be run directly from dojo's website or downloaded and > run > > locally without the server. Also, people trying to learn from the demos > tend > > to use the css provided for the purpose of the demo, which is not > > recommended. > > My rationale for removing the dojox is that these are marked as > > experimental by the dojo community and although some components are used > > often, keeping 6.8 MBs of code that is still experimental does not make > > sense. It is better to trust the dojo community to shift components from > > experimental to stable areas and then use them in further releases. > > > > Removing the stated components frees up about 8.7 MBs of space on the > > expanded server, which is huge for a javascript library. Since a Geronimo > > user can still include these components into his/her webapp we're not > really > > stopping them from using these components, only transferring the overhead > of > > using the lesser used components onto the user. > > -- > > Shrey Banga > > Bachelor of Technology, III year > > Department of Electrical Engineering > > Indian Institute of Technology Roorkee >
Re: [ANNOUNCE] Lin Sun is the newest member of the Geronimo PMC
Congratulations! Keep up the hard work Lin Sun! -Joseph Leong On Thu, Jun 26, 2008 at 2:22 PM, Dan Becker <[EMAIL PROTECTED]> wrote: > Jarek Gawor wrote: > >> Please join us in congratulating Lin Sun as the newest member of the >> Geronimo PMC. She has been involved with the Geronimo community for a >> long time and made great contributions as a committer and otherwise. >> She will be a great addition to the PMC. >> >> Congratulations Lin! >> > > Congratulations Lin Sun! > > -- > Thanks, Dan Becker >
[jira] Commented: (GERONIMO-4158) Plan Creator attempts to load old widget files after dijit migration
[ https://issues.apache.org/jira/browse/GERONIMO-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608068#action_12608068 ] Joseph Leong commented on GERONIMO-4158: Hi Shiva, This is nothing complicated by any stretch, and me just nitpicking to make the little things a little better. Correct me if i'm wrong, my apologies as i'm still learning about dojo, but on plugins/plancreator/plancreator-portlets/src/main/webapp/WEB-INF/view/configcreator/ejbPage.jsp There is a list of dojo.require of widgets. Looking at all the other files and how everything is now run on Dojo 1.1.1 with Dijit. That extra loading isn't necessary anymore? Also the dependency on them will be obsolete soon - also i believe that src is pointing to the location of 1.1.1 where the widgets don't reside anymore since they've been move to dojo/0.4/? If you can can confirm that, i'll submit a simple patch to clean that up and make sure nothing else is dependent on it. Thanks! -Joseph Leong > Plan Creator attempts to load old widget files after dijit migration > > > Key: GERONIMO-4158 > URL: https://issues.apache.org/jira/browse/GERONIMO-4158 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: PlanCreator >Affects Versions: 2.2 > Environment: Ubuntu 7.10, Firefox >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Trivial > Fix For: 2.2 > > > The plancreator-portlets has some leftover code that allocates resources for > loading the old widget system which will soon be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4158) Plan Creator attempts to load old widget files after dijit migration
Plan Creator attempts to load old widget files after dijit migration Key: GERONIMO-4158 URL: https://issues.apache.org/jira/browse/GERONIMO-4158 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Joseph Leong Priority: Trivial The plancreator-portlets has some leftover code that allocates resources for loading the old widget system which will soon be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4157) Generating plan for EAR on minimal install leads to Null Pointer Exception
[ https://issues.apache.org/jira/browse/GERONIMO-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607718#action_12607718 ] Joseph Leong commented on GERONIMO-4157: Note: It works fine on the geronimo-tomcat6-javaee5 build. -Joseph Leong > Generating plan for EAR on minimal install leads to Null Pointer Exception > -- > > Key: GERONIMO-4157 > URL: https://issues.apache.org/jira/browse/GERONIMO-4157 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: PlanCreator >Affects Versions: 2.2 > Environment: Ubuntu 7.10, Firefox 2.0.0.11 >Reporter: Joseph Leong > > When feeding the bank-ear-2.2-SNAPSHOT.ear into this plan creator on a > minimal-tomcat-6 server, it leads to a NPE: > java.lang.NullPointerException > > org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAfterView(GetArchiveHandler.java:71) > > org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) > org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145) > javax.servlet.http.HttpServlet.service(HttpServlet.java:713) > javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > > org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) > > org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) > > org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) > > org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) > > org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167) > javax.servlet.http.HttpServlet.service(HttpServlet.java:713) > javax.servlet.http.HttpServlet.service(HttpServlet.java:806) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4157) Generating plan for EAR on minimal install leads to Null Pointer Exception
Generating plan for EAR on minimal install leads to Null Pointer Exception -- Key: GERONIMO-4157 URL: https://issues.apache.org/jira/browse/GERONIMO-4157 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: PlanCreator Affects Versions: 2.2 Environment: Ubuntu 7.10, Firefox 2.0.0.11 Reporter: Joseph Leong When feeding the bank-ear-2.2-SNAPSHOT.ear into this plan creator on a minimal-tomcat-6 server, it leads to a NPE: java.lang.NullPointerException org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAfterView(GetArchiveHandler.java:71) org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167) javax.servlet.http.HttpServlet.service(HttpServlet.java:713) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4154) Converting Debugviews Portlet from Dojo 0.4->1.1.1
[ https://issues.apache.org/jira/browse/GERONIMO-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607373#action_12607373 ] Joseph Leong commented on GERONIMO-4154: Made changes in pom from dojo legacy to dojo. Started working on converting jmxmanager. -Joseph Leong > Converting Debugviews Portlet from Dojo 0.4->1.1.1 > -- > > Key: GERONIMO-4154 > URL: https://issues.apache.org/jira/browse/GERONIMO-4154 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Ubuntu 7.10 >Reporter: Joseph Leong >Assignee: Joseph Leong > > The conversion of the four components within debugview-portlet from Dojo 0.4 > widget system to Dojo 1.1.1's dijit system in attempt to upgrade Geronimo to > all 1.1.1 components. > 1) Classloaderview > 2) Dependencyview > 3) Jmxmanager > 4) JndiView -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4154) Converting Debugviews Portlet from Dojo 0.4->1.1.1
[ https://issues.apache.org/jira/browse/GERONIMO-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-4154: --- Description: The conversion of the four components within debugview-portlet from Dojo 0.4 widget system to Dojo 1.1.1's dijit system in attempt to upgrade Geronimo to all 1.1.1 components. 1) Classloaderview 2) Dependencyview 3) Jmxmanager 4) JndiView was:The conversion of the four components within debugview-portlet from Dojo 0.4 widget system to Dojo 1.1.1's dijit system in attempt to upgrade Geronimo to all 1.1.1 components. > Converting Debugviews Portlet from Dojo 0.4->1.1.1 > -- > > Key: GERONIMO-4154 > URL: https://issues.apache.org/jira/browse/GERONIMO-4154 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Ubuntu 7.10 > Reporter: Joseph Leong >Assignee: Joseph Leong > > The conversion of the four components within debugview-portlet from Dojo 0.4 > widget system to Dojo 1.1.1's dijit system in attempt to upgrade Geronimo to > all 1.1.1 components. > 1) Classloaderview > 2) Dependencyview > 3) Jmxmanager > 4) JndiView -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4154) Converting Debugviews Portlet from Dojo 0.4->1.1.1
Converting Debugviews Portlet from Dojo 0.4->1.1.1 -- Key: GERONIMO-4154 URL: https://issues.apache.org/jira/browse/GERONIMO-4154 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.2 Environment: Ubuntu 7.10 Reporter: Joseph Leong Assignee: Joseph Leong The conversion of the four components within debugview-portlet from Dojo 0.4 widget system to Dojo 1.1.1's dijit system in attempt to upgrade Geronimo to all 1.1.1 components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Welcome Shiva Kumar H R as the newest member of the Geronimo PMC
Congratulations Shiva! Keep up the great work! -Joseph Leong On Mon, Jun 23, 2008 at 11:17 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > Congrats! > > > -Donald > > > > Vamsavardhana Reddy wrote: > >> All, >> Please join us in congratulating Shiva Kumar H R as the newest member of >> the Geronimo PMC. It's been great to have Shiva working with us as a >> committer on Geronimo. Even better to have him join us in providing >> oversight of the Geronimo project. >> >> Way to go Shiva!!! >> >> The Apache Geronimo PMC >> >> ++Vamsi >> >
Re: Dojo 0.4.x -> Dojo 1.1.1 Upgrade
);
dojo.require("dojo.widget.TreeBasicControllerV3");
dojo.require("dojo.widget.TreeSelectorV3");
dojo.require("dojo.widget.TreeEmphasizeOnSelect");
dojo.require("dojo.widget.TreeToggleOnSelect");
1e)debugviews-portlets/ldapmanager
Dojo 0.4
dojo.require("dojo.lang.*");
dojo.require("dojo.widget.*");
dojo.require("dojo.widget.ContentPane");
dojo.require("dojo.widget.LayoutContainer");
dojo.require("dojo.widget.SplitContainer");
dojo.require("dojo.widget.Tree");
dojo.require("dojo.widget.TreeBasicController");
dojo.require("dojo.widget.TreeContextMenu");
dojo.require("dojo.widget.TreeSelector");
dojo.require("dojo.widget.TabContainer");
dojo.require("dojo.widget.SortableTable");
dojo.require("dojo.widget.ComboBox");
dojo.require("dojo.widget.Tooltip");
dojo.require("dojo.widget.validate");
*** mconsole-war ***
2)mconsole-war
dojo.require("dojox.charting.Chart2D");
dojo.require("dojox.charting.themes.PlotKit.blue");
dojo.require("dojox.fx.easing");
*** plancreator-portlets
3)/plancreator-portlets/src/main/webapp/WEB-INF/view/configcreator/ejbPage.jsp
dojo.require("dojo.lang.*");
dojo.require("dojo.widget.*");
dojo.require("dojo.widget.ContentPane");
dojo.require("dojo.widget.LayoutContainer");
dojo.require("dojo.widget.SplitContainer");
dojo.require("dojo.widget.Tree");
dojo.require("dojo.widget.TreeBasicController");
dojo.require("dojo.widget.TreeContextMenu");
dojo.require("dojo.widget.TreeSelector");
dojo.require("dojo.widget.SortableTable");
dojo.require("dojo.widget.ComboBox");
dojo.require("dojo.widget.Tooltip");
dojo.require("dojo.widget.validate");
Sincerely,
-Joseph Leong
On Fri, Jun 20, 2008 at 4:38 PM, Kevan Miller <[EMAIL PROTECTED]>
wrote:
>
> On Jun 20, 2008, at 3:19 PM, Joseph Leong wrote:
>
> Hi all,
>
> So i've inventoried what i could find in trunk with items that are using
> Dojo, provided is a list of the location and some of the widgets they are
> using that will be needed to convert to Dojo's 1.1.1 dijit package.
> References to Dojo's Dijit can be found at:
> http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit-0
> I'm going to start converting the code from the top, item 1 and on down,
> feel free to make any suggestions Thanks! I'll keep everyone posted on
> progress.
>
>
> Hi Joe,
> Sounds good to me. Probably want to create at least 4 jira's to track this
> work. Assume these are separable pieces of work. Would prefer to see
> multiple patches, rather than one big one... Also, leaves room for others to
> chip in...
>
> --kevan
>
>
>
> *** console-base-portlets ***
> 1a)console-base-portlets/dependencyview
> dojo.require("dojo.widget.*");
> dojo.require("dojo.widget.TreeV3");
> dojo.require("dojo.widget.TreeNodeV3");
> dojo.require("dojo.widget.TreeBasicControllerV3");
> dojo.require("dojo.widget.TreeSelectorV3");
> dojo.require("dojo.widget.TreeEmphasizeOnSelect");
> dojo.require("dojo.widget.TreeToggleOnSelect");
>
> 1b)console-base-portlets/jndiview
> dojo.require("dojo.widget.*");
> dojo.require("dojo.widget.TreeV3");
> dojo.require("dojo.widget.TreeNodeV3");
> dojo.require("dojo.widget.TreeBasicControllerV3");
> dojo.require("dojo.widget.TreeSelectorV3");
> dojo.require("dojo.widget.TreeEmphasizeOnSelect");
> dojo.require("dojo.widget.TreeToggleOnSelect");
>
> *** debug-view-portlets ***
> 2a)debugviews-portlets/classloaderview
> Dojo 0.4
> dojo.require("dojo.lang.*");
> dojo.require("dojo.widget.*");
> dojo.require("dojo.widget.ContentPane");
> dojo.require("dojo.widget.LayoutContainer");
> dojo.require("dojo.widget.SplitContainer");
> dojo.require("dojo.widget.Tree");
> dojo.require("dojo.widget.TreeBasicController");
> dojo.require("dojo.widget.TreeContextMenu");
> dojo.require("dojo.widget.TreeSelector");
> dojo.require("dojo.widget.TabContainer");
> dojo.require("dojo.widget.SortableT
Dojo 0.4.x -> Dojo 1.1.1 Upgrade
ojo.require("dojo.widget.ContentPane");
dojo.require("dojo.widget.LayoutContainer");
dojo.require("dojo.widget.SplitContainer");
dojo.require("dojo.widget.Tree");
dojo.require("dojo.widget.TreeBasicController");
dojo.require("dojo.widget.TreeContextMenu");
dojo.require("dojo.widget.TreeSelector");
dojo.require("dojo.widget.TabContainer");
dojo.require("dojo.widget.SortableTable");
dojo.require("dojo.widget.ComboBox");
dojo.require("dojo.widget.Tooltip");
dojo.require("dojo.widget.validate");
dojo.require("dojo.widget.*");
dojo.require("dojo.widget.TreeV3");
dojo.require("dojo.widget.TreeNodeV3");
dojo.require("dojo.widget.TreeBasicControllerV3");
dojo.require("dojo.widget.TreeSelectorV3");
dojo.require("dojo.widget.TreeEmphasizeOnSelect");
dojo.require("dojo.widget.TreeToggleOnSelect");
2e)debugviews-portlets/ldapmanager
Dojo 0.4
dojo.require("dojo.lang.*");
dojo.require("dojo.widget.*");
dojo.require("dojo.widget.ContentPane");
dojo.require("dojo.widget.LayoutContainer");
dojo.require("dojo.widget.SplitContainer");
dojo.require("dojo.widget.Tree");
dojo.require("dojo.widget.TreeBasicController");
dojo.require("dojo.widget.TreeContextMenu");
dojo.require("dojo.widget.TreeSelector");
dojo.require("dojo.widget.TabContainer");
dojo.require("dojo.widget.SortableTable");
dojo.require("dojo.widget.ComboBox");
dojo.require("dojo.widget.Tooltip");
dojo.require("dojo.widget.validate");
*** mconsole-war ***
3)mconsole-war
dojo.require("dojox.charting.Chart2D");
dojo.require("dojox.charting.themes.PlotKit.blue");
dojo.require("dojox.fx.easing");
*** plancreator-portlets
4)/plancreator-portlets/src/main/webapp/WEB-INF/view/configcreator/ejbPage.jsp
dojo.require("dojo.lang.*");
dojo.require("dojo.widget.*");
dojo.require("dojo.widget.ContentPane");
dojo.require("dojo.widget.LayoutContainer");
dojo.require("dojo.widget.SplitContainer");
dojo.require("dojo.widget.Tree");
dojo.require("dojo.widget.TreeBasicController");
dojo.require("dojo.widget.TreeContextMenu");
dojo.require("dojo.widget.TreeSelector");
dojo.require("dojo.widget.SortableTable");
dojo.require("dojo.widget.ComboBox");
dojo.require("dojo.widget.Tooltip");
dojo.require("dojo.widget.validate");
Sincerely,
-Joseph Leong
[jira] Commented: (GERONIMO-3599) Unable to create new JMS Resource group through console in IE7
[ https://issues.apache.org/jira/browse/GERONIMO-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606502#action_12606502 ] Joseph Leong commented on GERONIMO-3599: So it seems even if we just shorten the var argument length, if the user increases their input enough - we still will run into this issue? It seems also with the way pluto works and the response it send back might be so big that reducing my var arguments by a few char may still greatly fall short of resolving the 2084 limit. Does anyone have any comments/ideas about if i approached passing the information through a portlet session? Would that resolve the url issue by keeping information server side? > Unable to create new JMS Resource group through console in IE7 > -- > > Key: GERONIMO-3599 > URL: https://issues.apache.org/jira/browse/GERONIMO-3599 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0.1 > Environment: WIN XP >Reporter: Anish Pathadan >Assignee: Joseph Leong > Fix For: 2.1.2, 2.1.x, 2.2 > > > I am not able to create a new JMS Resouce group through console. I am getting > cannot display the page error after entering the Q name and physical name and > then pressing next. > The following is the url > http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1 > The problem only comes with Internet Explorer 7. > Best Regards, > Anish Pathadan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3599) Unable to create new JMS Resource group through console in IE7
[ https://issues.apache.org/jira/browse/GERONIMO-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606036#action_12606036 ] Joseph Leong commented on GERONIMO-3599: Trying to go through and recreate the same URL error. I'm not able to recreate the error with the similar URL pattern in 2.1, but still coming upon an error with the page not loading. It seems i am able to create one item, but anything afterwards will results in an error. Procedure as follow: Branch 2.0 1)Create a new JMS Resource Group->For ActiveMQ 2)Fill in Resource Group Name 3)Add Connection Factory->Fill in Connection Factory Name 4)Add Another Connection Factory [Error Url] http://localhost:8080/console/portal/services/services_jms/_ac_services_jms_row1_col1_p1/AC/_ps_services_jms_row1_col1_p1/normal/_pid/services_jms_row1_col1_p1/_pm_services_jms_row1_col1_p1/view/_md_services_jms_row1_col1_p1/view/_st_services_jms_row1_col1_p1/normal Branch 2.1 1)Create a new JMS Resource Group->For ActiveMQ 2)Fill in Resource Group Name 3)Add Connection Factory->Fill in Connection Factory Name 4)Add Another Connection Factory [Error Url] http://localhost:8080/console/portal//Services/JMS%20Resources/__ac0x3activemq0x2JMSWizard!1082939780%7C0/__pm0x3activemq0x2JMSWizard!1082939780%7C0_view > Unable to create new JMS Resource group through console in IE7 > -- > > Key: GERONIMO-3599 > URL: https://issues.apache.org/jira/browse/GERONIMO-3599 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0.1 > Environment: WIN XP > Reporter: Anish Pathadan >Assignee: Joseph Leong > Fix For: 2.1.2, 2.1.x, 2.2 > > > I am not able to create a new JMS Resouce group through console. I am getting > cannot display the page error after entering the Q name and physical name and > then pressing next. > The following is the url > http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1 > The problem only comes with Internet Explorer 7. > Best Regards, > Anish Pathadan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Upgrading to Dojo 1.1.1
Ok great, so now there's a starting point. Seems the community is in favor, so i'll start going through and inventorying what we have currently running in what parts of AG and see if i can propose a plan for changes so the work can be parallelize should others want to jump in. Also, to track progress as you were all saying. Thanks for the input! -Joseph Leong On Fri, Jun 6, 2008 at 12:35 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > On Jun 6, 2008, at 12:19 PM, Donald Woods wrote: > > +1 for trunk. >> > > I was assuming trunk in my discussion. > > >> Can you also move the older versions out of trunk and into the >> geronimo/plugins branch, so people can optionally install them if their app >> still needs them? >> >> If you're wanting to also do this in branches/2.1, then we need to keep >> the older version in the server images, so we don't break existing apps that >> may need them and so we can warn users that we will be removing them in the >> next release (2.2.) >> > > I was thinking that we could release older versions of dojo as separate > plugins. So, if somebody wanted a "legacy" level, they could install the > appropriate legacy dojo plugin. No reason, however, not to release the dojo > plugin separately (rather than have the latest version included in > server...). > > --kevan >
[jira] Commented: (GERONIMO-3599) Unable to create new JMS Resource group through console in IE7
[ https://issues.apache.org/jira/browse/GERONIMO-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603076#action_12603076 ] Joseph Leong commented on GERONIMO-3599: Continuing progress on this now, put it on the side for a little bit. I think to keep the post length below 2084 i'll go through and reduce the parameter names and see if that will keep it below 2084. If not, maybe i'll try passing it through portletsessions. -Joseph Leong > Unable to create new JMS Resource group through console in IE7 > -- > > Key: GERONIMO-3599 > URL: https://issues.apache.org/jira/browse/GERONIMO-3599 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0.1 > Environment: WIN XP > Reporter: Anish Pathadan >Assignee: Joseph Leong > Fix For: 2.1.2, 2.1.x, 2.2 > > > I am not able to create a new JMS Resouce group through console. I am getting > cannot display the page error after entering the Q name and physical name and > then pressing next. > The following is the url > http://localhost:8080/console/portal/services/services_jms/_ps_services_jms_row1_col1_p1/normal/_pm_services_jms_row1_col1_p1/view/_ac_services_jms_row1_col1_p1/AC/_st_services_jms_row1_col1_p1/normal/_md_services_jms_row1_col1_p1/view/_pid/services_jms_row1_col1_p1 > The problem only comes with Internet Explorer 7. > Best Regards, > Anish Pathadan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Upgrading to Dojo 1.1.1
Hi everyone, I've been tossing the idea around in my head of taking the initiative to upgrade the current items written in Dojo to 1.1.1, I know we still have some Dojo 0.4.3, which isn't supported anymore, in use and there has been vast improvements with their new Dijit package for widgets among many other items. Also, with some recently reported JIRAs about accessibility compatibility being an issue in these Dojo components we can make use of the a11y available in it. Overall, i also think we might also benefit a cleaner setup from streamlining our versions in terms of future development and maintenance as well. Although I haven't looked in complete detail in each of the AG Dojo pieces, i know that the 0.4.3 transition to 1.1.1 will take some work because the widget system has been separated out to it's own pieces (diji) and so simple work arounds will not do. That is, this will be a big block change rather than an incremental one. Does anyone have any thoughts - one way or the other on this undertaking? Thanks! Joseph Leong
[jira] Commented: (GERONIMO-4030) Accessibility issue: The tree and tabbed content in Debug views is not keyboard navigatable
[ https://issues.apache.org/jira/browse/GERONIMO-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602702#action_12602702 ] Joseph Leong commented on GERONIMO-4030: So it's confirmed that DOJO supports tabindex. However, for elements that have no role such as DIV, IMG, and SPAN a role must be defined for them first before the tabindex attribute can be used. Furthermore, for objects with hierarchy such as the tree/tree nodes in this debugview portlet, a hierarchy role must be defined between the parent/childs so navigation will be done properly. TabIndex -1 removes elements in the tabbing order, Tabindex 0 is what the document tab order will be relative to in that document. Otherwise tabindex 1 to 32768 can be assigned. Any other insight appreciated. Thanks! Joseph Leong > Accessibility issue: The tree and tabbed content in Debug views is not > keyboard navigatable > --- > > Key: GERONIMO-4030 > URL: https://issues.apache.org/jira/browse/GERONIMO-4030 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 > JAWS 8.0 > Reporter: Xia Ming >Assignee: Joseph Leong > > To enable blind people smoothly use admin console, all of part in the admin > console pages should be keyboard navigatable. > But in Debug Views pages, the object trees and tabbed content are not > keyboard navigatable, JAWS just read the portlet title and stop there, no > keyboard action could be used to enter the content. > The impact pages include: > Debug Views->JMX Viewer, LDAP Viewer, Classloader Viewer, JNDI Viewer, > Dependency Viewer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602406#action_12602406 ] Joseph Leong commented on GERONIMO-4027: Quick additional comment. Additionally the background image is being grabbed from the templateCssString rather than any reference to the TreeIcon CSS file itself. The templateCssString is defined in each respective view files. The reason templateCssString was used instead of having an overriding CSS Template file is because in dojo 0.4.x this particular widget (among others) has a glitch that causes that attribute to not function at all. -Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 >Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-4027-2.patch, GERONIMO-4027.patch > > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602402#action_12602402 ] Joseph Leong commented on GERONIMO-4027: Hi Lin, Thanks for looking it over. I see why you would say that, but not to worry - I specifically commented that portion out. The hard-coded address in the TreeIcon CSS file was just there for me to use while debugging. Good spot though, i almost didn't catch it myself the first time. -Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 > Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-4027-2.patch, GERONIMO-4027.patch > > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4030) Accessibility issue: The tree and tabbed content in Debug views is not keyboard navigatable
[ https://issues.apache.org/jira/browse/GERONIMO-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong reassigned GERONIMO-4030: -- Assignee: Joseph Leong > Accessibility issue: The tree and tabbed content in Debug views is not > keyboard navigatable > --- > > Key: GERONIMO-4030 > URL: https://issues.apache.org/jira/browse/GERONIMO-4030 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 > JAWS 8.0 >Reporter: Xia Ming >Assignee: Joseph Leong > > To enable blind people smoothly use admin console, all of part in the admin > console pages should be keyboard navigatable. > But in Debug Views pages, the object trees and tabbed content are not > keyboard navigatable, JAWS just read the portlet title and stop there, no > keyboard action could be used to enter the content. > The impact pages include: > Debug Views->JMX Viewer, LDAP Viewer, Classloader Viewer, JNDI Viewer, > Dependency Viewer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4030) Accessibility issue: The tree and tabbed content in Debug views is not keyboard navigatable
[ https://issues.apache.org/jira/browse/GERONIMO-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602366#action_12602366 ] Joseph Leong commented on GERONIMO-4030: In existing practices, the attribute tabOrder or tabIndex assigns the tabbing ordering for certain web elements that the selection cycles through when pressing the tab key. However, i'm uncertain if these dojo pieces would allow for this attribute to work. I'll poke around and see if i can figure something out. Any suggestions are appreciated! Thanks -Joseph Leong > Accessibility issue: The tree and tabbed content in Debug views is not > keyboard navigatable > --- > > Key: GERONIMO-4030 > URL: https://issues.apache.org/jira/browse/GERONIMO-4030 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 > JAWS 8.0 >Reporter: Xia Ming > > To enable blind people smoothly use admin console, all of part in the admin > console pages should be keyboard navigatable. > But in Debug Views pages, the object trees and tabbed content are not > keyboard navigatable, JAWS just read the portlet title and stop there, no > keyboard action could be used to enter the content. > The impact pages include: > Debug Views->JMX Viewer, LDAP Viewer, Classloader Viewer, JNDI Viewer, > Dependency Viewer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-4027: --- Attachment: GERONIMO-4027-2.patch Commented out TreeDoc CSS because it's no longer being used and erased duplicate widget code. -Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 >Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-4027-2.patch, GERONIMO-4027.patch > > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602290#action_12602290 ] Joseph Leong commented on GERONIMO-4027: LDAP Viewer icons verified. Posted patch includes all necessary changes for this Jira! -Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 >Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-4027.patch > > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-4027: --- Attachment: GERONIMO-4027.patch High contrast icons implemented for: ClassLoader Viewer JNDI Viewer Dependency Viewer Patch posted, pending that i am still verifying LDAP Viewer for high contrast icons once i get a local DS setup. If no icons needed to be changed there, the posted patch is final. > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 >Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-4027.patch > > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602053#action_12602053 ] Joseph Leong commented on GERONIMO-4027: It turns out in some widgets of Dojo 0.4.x , TreeIconExtension being one, there is a bug where the templateCssPath parameter is ignored. As such, a templateCssString will be passed through defining the custom CSS as well as skipping the step of resolving file reference. -Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 >Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601993#action_12601993 ] Joseph Leong commented on GERONIMO-4027: The icons are currently looking at a predefined templated css that is packaged with Dojo 0.4.3 and that css specifies to icon paths that do not exist. Rather than uploading additional icons to the package, i'll modify the TreeDocIcon.css at the root of debug-views and have that take precedence as the CSS to define those icon. This css will have attributes to point to the high contrast icon which already exist at debug-views/ Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 > Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600881#action_12600881 ] Joseph Leong commented on GERONIMO-4027: I guess i wouldn't modify the 3rd party lib, the problem might come back when upgrading the lib and possibly more overhead for maintaining a private build. Thoughts? So it looks like the css linking to the icon just appears to be broken. Modifying that piece and testing to make sure that was the only issue. -Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 > Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600785#action_12600785 ] Joseph Leong commented on GERONIMO-4027: Hi Rex, I'll take a look at your lead and see what else i can do. Thanks! -Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 > Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4027) Accessibility issue: Tree icons in high contrast mode cannot be seen
[ https://issues.apache.org/jira/browse/GERONIMO-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong reassigned GERONIMO-4027: -- Assignee: Joseph Leong > Accessibility issue: Tree icons in high contrast mode cannot be seen > > > Key: GERONIMO-4027 > URL: https://issues.apache.org/jira/browse/GERONIMO-4027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.1 > Environment: Windows XP SP2, IE 6.0 >Reporter: Xia Ming >Assignee: Joseph Leong >Priority: Minor > > To enable low-vision people to use admin console, the tree icons in these > pages shall be improved: > Classloader tree > JNDI tree > Dependency tree > Note that, after tested, only MBeans tree's icon could be seen in the high > contrast mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4070) Plugin installer fails to install after previous attempt of a plugin has failed.
[ https://issues.apache.org/jira/browse/GERONIMO-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600513#action_12600513 ] Joseph Leong commented on GERONIMO-4070: Doesn't appear that the previous changes to fix the similar container issues have been removed. The list of what is being installed is created and upon failure goes through to remove the configuration. Going to dig deeper to find what else has changed. Joseph Leong > Plugin installer fails to install after previous attempt of a plugin has > failed. > > > Key: GERONIMO-4070 > URL: https://issues.apache.org/jira/browse/GERONIMO-4070 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Ubuntu 7.10, Firefox > Reporter: Joseph Leong >Assignee: Joseph Leong > > When the plugin installer fails installing a plugin.. for whatever reason.. > missing dependency/file etc.. the following attempt to install another plugin > will be unsuccessful because it tries to load/start the configuration that > failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4070) Plugin installer fails to install after previous attempt of a plugin has failed.
[ https://issues.apache.org/jira/browse/GERONIMO-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600238#action_12600238 ] Joseph Leong commented on GERONIMO-4070: We did have a similar problem before, but a little different. Previously the plugin installer had this failure when installing a plugin for the wrong container (ie-Installing a jetty configuration plugin in Tomcat and vise versa). Checking to see if any changes have been reverted or canceled out. Do you think it might be more appropriate to just re-open the other JIRA related to the container specifically? -Joseph Leong > Plugin installer fails to install after previous attempt of a plugin has > failed. > > > Key: GERONIMO-4070 > URL: https://issues.apache.org/jira/browse/GERONIMO-4070 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 > Environment: Ubuntu 7.10, Firefox >Reporter: Joseph Leong >Assignee: Joseph Leong > > When the plugin installer fails installing a plugin.. for whatever reason.. > missing dependency/file etc.. the following attempt to install another plugin > will be unsuccessful because it tries to load/start the configuration that > failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4070) Plugin installer fails to install after previous attempt of a plugin has failed.
Plugin installer fails to install after previous attempt of a plugin has failed. Key: GERONIMO-4070 URL: https://issues.apache.org/jira/browse/GERONIMO-4070 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Joseph Leong When the plugin installer fails installing a plugin.. for whatever reason.. missing dependency/file etc.. the following attempt to install another plugin will be unsuccessful because it tries to load/start the configuration that failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4068) The jms-mdb-sample app error->home link isn't redirecting back to the home properly
[ https://issues.apache.org/jira/browse/GERONIMO-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-4068: --- Attachment: GERONIMO-4068.patch > The jms-mdb-sample app error->home link isn't redirecting back to the home > properly > --- > > Key: GERONIMO-4068 > URL: https://issues.apache.org/jira/browse/GERONIMO-4068 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: sample apps >Affects Versions: 2.2 > Environment: Ubuntu 7.10, Firefox > Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-4068.patch > > > In the jms-mdb-sample application. When an error occurs in the application > the home link redirects incorrectly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4068) The jms-mdb-sample app error->home link isn't redirecting back to the home properly
The jms-mdb-sample app error->home link isn't redirecting back to the home properly --- Key: GERONIMO-4068 URL: https://issues.apache.org/jira/browse/GERONIMO-4068 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: sample apps Affects Versions: 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor In the jms-mdb-sample application. When an error occurs in the application the home link redirects incorrectly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4059) Bank app error screen returns to page creating duplicate header.
[ https://issues.apache.org/jira/browse/GERONIMO-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-4059: --- Attachment: GERONIMO-4059.patch Redirects to the jsp page instead of the html which creates the additional header inlays. -Joseph Leong > Bank app error screen returns to page creating duplicate header. > > > Key: GERONIMO-4059 > URL: https://issues.apache.org/jira/browse/GERONIMO-4059 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: sample apps >Affects Versions: 2.2 > Environment: Ubuntu 7.10, Firefox >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Trivial > Attachments: GERONIMO-4059.patch > > > In the Bank Sample application, when a user reaches the error screen and > attempts to return to the homepage the header is duplicated and starts to > create an inlay of headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4059) Bank app error screen returns to page creating duplicate header.
Bank app error screen returns to page creating duplicate header. Key: GERONIMO-4059 URL: https://issues.apache.org/jira/browse/GERONIMO-4059 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: sample apps Affects Versions: 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Joseph Leong Priority: Trivial In the Bank Sample application, when a user reaches the error screen and attempts to return to the homepage the header is duplicated and starts to create an inlay of headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] ASF hosted machines for TCK Proposal
+1 On Tue, May 20, 2008 at 8:22 AM, Joe Bohn <[EMAIL PROTECTED]> wrote: > If we are to take this proposal forward to the ASF Infrastructure team, > they want assurance that the Geronimo PMC is behind the recommendation and > supports the intended use of the systems. I think it also bodes well to > demonstrate that the entire Geronimo community stands behind the proposal, > particularly since we will administer the machines ourselves, - so I > encourage all to vote. > > > [ ] +1 I agree with the need and support the proposal. Present it to the > ASF Infrastructure team. > [ ] 0 No opinion > [ ] -1 I don't see the need or disagree with the proposal. Do not present > this proposal to the ASF Infrastructure team. > > I'll plan on calling this vote on Friday (5/23) morning (9 AM EST). > > > PROPOSAL > > Rationale: > The Apache Geronimo community has a need to support the execution and > sharing of results from Sun certification tests (cts) which are necessary > gain JavaEE5 certification compliance. This information is only available > to those Geronimo committers that have signed the Sun NDA and other Apache > committers that have signed an NDA and gained approval of the Apache > Geronimo PMC. This has allowed other Apache projects to test new > products/releases by running JavaEE 5 TCK tests using the Apache Geronimo > test infrastructure. > > In the past these resource intensive tests have been run on private > machines by individuals. As more people become involved with Apache > Geronimo and related projects, it is becoming obvious that we need a central > system to run and share the results of these tests. A centralized testing > environment allows the Geronimo community to more fully participate in the > TCK process. Some committers don't have access to the hardware resources > needed to run the Java EE TCK tests in a timely manner. Although some ad-hoc > sharing of private machines has occurred, this is not ideal from a community > perspective. Community controlled systems allow us to equitably share these > resources. > > Request: > To fulfill this requirement, the Apache Geronimo PMC is requesting the ASF > infrastructure team to provide and host machines that can be used for this > purpose. Initially, we would like to request two (2) machines that meet (as > closely as possible) the specification below. However, we can see the need > for 2 additional machines in the not too distant future. > > Machine specs: > - 8 core (two 3.0 GHz quad-core) > - 16 GB memory > - two 750GB 7200 - rpm SATA 3GB/s disks > - DVD R/W (20x?) > - rack mountable specification to work with ASF infra requirements > - LOM or other features as necessary for ASF infra support > - to be developer managed and maintained by the Apache Geronimo Team > - Apache Geronimo would assume all responsibility for: > - configuration > - backup/recovery > - secure access >- Strictly limited to those Apache Geronimo committers with NDAs on > file or additional Apache committers with NDAs and approved by Geronimo PMC. > - full, admin access would be granted to ASF infra with reboot directions > - At least 2 active Apache Geronimo committers (with NDA authorization) > would identified to manage the machines. > - Running Linux with something like Xen for 4 VM images per machine. We > may increase the number of VM images if it is feasible. > - We would require both ssh and VNC access to the VMs. > - It is not yet decided if we would use NAT to access the VMs or public IP > addresses. Is there are recommendation from ASF Infra? > - Automation will most likely be added to run builds, execute tests, and > produce reports. > - Capability to manually run tests on demand would also be supported. > > Admin Volunteers: > - Joe Bohn (PMC) > - Jay McHugh (PMC) > - Jason Warner > - Matt Hogstrom (PMC) > - Kevan Miller (PMC) >
Re: Google Analytics
Kevan, I think that suggestion makes sense. I guess on that note, if you could add [EMAIL PROTECTED] for "User" rights to the group. Thanks! -Joseph Leong On Fri, May 16, 2008 at 11:41 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > On May 16, 2008, at 11:03 AM, Joe Bohn wrote: > > Kevan Miller wrote: > > On May 15, 2008, at 2:32 AM, David Blevins wrote: > > Setup google analytics on all our spaces and added everyone who's a > committer who I could easily find a gmail address for. > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]> > > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] <[EMAIL PROTECTED]>> > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > You don't need a gmail address, just a google account. So if you're not in > the above list, just get someone in the above list to add your google > account. > > > Just visit http://www.google.com/analytics/ to log in and view the data. > It'll be a day or two before we see much of anything. > > Thanks David. > > I've added everyone that's requested access to date, except Dan Becker. I > gave all PMC members "Administrator" access. Committers have "User" access. > > What should we do about non-committers requesting access? I don't know why > we wouldn't make this information available to anyone who asks. > > Are there any general privacy issues? If there are, then we should be aware > of these issues, even if we don't open up access. > > If people are interested, I see we can set up a regular email of reports. > > --kevan > > > > Thanks Kevan! It works for me. > > I don't think the information poses any privacy issue concerns so I think > it would be ok to open it up to non-committers. Should we be concerned that > somebody could use this against us in some fashion - perhaps to demonstrate > how some other project is getting more interest than G based on hit volumes? > If that is not a concern then I think an email report to dev would perhaps > lessen the need to manage a large list of non-committers. > > > Don't know how the data might be used. But don't think we have anything to > hide, either... > > I wouldn't want to cause email clutter with reports. Not sure if reports > can be grouped in a single email, etc. Also not sure what information might > be useful. For now, I might just let people access the data. If we think > email reports would be useful, then we can set that up at anytime... > > So, I would give PMC members "Administrator" rights to the group, > committers and anyone who asks "User" rights to the groups. Anyone see > issues with that? > > --kevan > >
Re: [DISCUSS] Policy for granting write access to our Wiki
Just as Dan said, I think a lightweight process would be a good idea. Not to deter users from contributing, nor hinder those approving. If we haven't had a problem with the Jira check-box format for IP reasons, this seems like not only a lightweight process but a familiar one at that. -Joseph Leong On Thu, Apr 17, 2008 at 8:37 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > On Apr 16, 2008, at 7:34 PM, Gianny Damour wrote: > > I am supportive of Erik's suggestion. I am absolutely against a process > > involving the submission of an iCLA. > > > > Is a checkbox really required? Isn't a disclaimer enough to protect IP > > rights? > > > > Well, I think we can assume that a checkbox was a requirement for > Jira-based submissions (a disclaimer was not sufficient). Since, Wiki > submissions are essentially the same, I don't think a simple disclaimer will > be sufficient... > > --kevan > >
[jira] Updated: (GERONIMO-3955) Typo
[ https://issues.apache.org/jira/browse/GERONIMO-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3955: --- Patch Info: [Patch Available] > Typo > > > Key: GERONIMO-3955 > URL: https://issues.apache.org/jira/browse/GERONIMO-3955 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 >Reporter: Afranio Moraes >Assignee: Joseph Leong >Priority: Trivial > Attachments: GERONIMO-3955.patch > > > Typo in console after editing keystores: > Keysore 'keystore.jks' is now edit locked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3955) Typo
[ https://issues.apache.org/jira/browse/GERONIMO-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3955: --- Attachment: GERONIMO-3955.patch > Typo > > > Key: GERONIMO-3955 > URL: https://issues.apache.org/jira/browse/GERONIMO-3955 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 >Reporter: Afranio Moraes >Assignee: Joseph Leong >Priority: Trivial > Attachments: GERONIMO-3955.patch > > > Typo in console after editing keystores: > Keysore 'keystore.jks' is now edit locked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3955) Typo
[ https://issues.apache.org/jira/browse/GERONIMO-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong reassigned GERONIMO-3955: -- Assignee: Joseph Leong > Typo > > > Key: GERONIMO-3955 > URL: https://issues.apache.org/jira/browse/GERONIMO-3955 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 >Reporter: Afranio Moraes >Assignee: Joseph Leong >Priority: Trivial > > Typo in console after editing keystores: > Keysore 'keystore.jks' is now edit locked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Jason Warner as Geronimo's most recent committer
Hurray! Congratulations Jason! -Joseph Leong On Wed, Apr 2, 2008 at 2:31 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > Congrats Jason! > > --kevan > > On Apr 2, 2008, at 2:22 PM, Joe Bohn wrote: > > All, > > > > It is my privilege to announce that Jason has recently accepted an > > invitation to join the Apache Geronimo project. Jason has been working on > > Geronimo for a while now in multiple areas including J2G, javamail, G-shell > > commands, samples, and many more things. He is always eager to help users > > and goes the extra mile to ensure issues are addressed. We're grateful to > > have him on the project. Please give it up for Jason. > > > > Joe > > > >
[jira] Commented: (GERONIMO-3942) IllegalStateException warning message for Jetty plugin installer
[ https://issues.apache.org/jira/browse/GERONIMO-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583744#action_12583744 ] Joseph Leong commented on GERONIMO-3942: Looks like the plugin installer is attempting to write to the output stream after a response has been committed. Checking to see if the RequestDispatcher.forward and HttpServletResponse.sendRedirect are the last methods called before the end of the methods. > IllegalStateException warning message for Jetty plugin installer > > > Key: GERONIMO-3942 > URL: https://issues.apache.org/jira/browse/GERONIMO-3942 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 > Environment: Ubuntu 7.10, Firefox >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Fix For: 2.2 > > > When installing plugins via the admin console (on Jetty) , at times an > IllegalStateException Warning Message Occurs. Otherwise, everything appears > to look and work fine functionality wise. > StackTrace Example: > java.lang.IllegalStateException: Committed > at org.mortbay.jetty.Response.resetBuffer(Response.java:995) > at org.mortbay.jetty.Response.sendRedirect(Response.java:403) > at > org.mortbay.jetty.security.FormAuthenticator.authenticate(FormAuthenticator.java:257) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.checkSecurityConstraints(JettySecurityHandler.java:216) > at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:191) > at > org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) > at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) > at > org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) > at > org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) > at > org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58) > at > org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) > at > org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) > at > org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle(TwistyWebAppContext.java:59) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:324) > at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:374) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong closed GERONIMO-3781. -- Resolution: Fixed Original CRSF issue resolved. The side effect spawn the warning message in Jetty will be fixed and updated at GERONIMO-3942 > Plugin Installer, CRSF issue when attempting to install a new plugin > > > Key: GERONIMO-3781 > URL: https://issues.apache.org/jira/browse/GERONIMO-3781 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1 > Environment: Ubuntu 7.10, Firefox 2.0.0.6 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1 > > > Plugin installer will not allow for you to install anymore plugins on a > second attempt given that it threw an exception the first time. This is > attributed to the exception thrown that doesn't properly exit and close off > current sessions. So in the second attempt there is a cookie/session > mismatch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3942) IllegalStateException warning message for Jetty plugin installer
IllegalStateException warning message for Jetty plugin installer Key: GERONIMO-3942 URL: https://issues.apache.org/jira/browse/GERONIMO-3942 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.2 When installing plugins via the admin console (on Jetty) , at times an IllegalStateException Warning Message Occurs. Otherwise, everything appears to look and work fine functionality wise. StackTrace Example: java.lang.IllegalStateException: Committed at org.mortbay.jetty.Response.resetBuffer(Response.java:995) at org.mortbay.jetty.Response.sendRedirect(Response.java:403) at org.mortbay.jetty.security.FormAuthenticator.authenticate(FormAuthenticator.java:257) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.checkSecurityConstraints(JettySecurityHandler.java:216) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:191) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle(TwistyWebAppContext.java:59) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:374) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3939) Failing to start plugin after install if previous plugin install failed.
[ https://issues.apache.org/jira/browse/GERONIMO-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong resolved GERONIMO-3939. Resolution: Fixed Issue resolved and committed with patch in trunk (revision 641849) and branches/2.1 (revision 641851) Refer to GERONIMO-3887 for full details > Failing to start plugin after install if previous plugin install failed. > > > Key: GERONIMO-3939 > URL: https://issues.apache.org/jira/browse/GERONIMO-3939 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 > Environment: Ubuntu 7.10, Firefox >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > > The admin console plugin installer fails to start a plugin after install > under the condition that a previous plugin install failed. > The plugin installer is hung on the cache of the previous failed install and > won't start or show the progress of the new plugin install. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
[ https://issues.apache.org/jira/browse/GERONIMO-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3887: --- Attachment: GERONIMO-3887-2.patch My mistake, moved the try / catch inside the loop. Patch 2 posted. > After installing with wrong configuration unable to proceed with any new > plugin installs > > > Key: GERONIMO-3887 > URL: https://issues.apache.org/jira/browse/GERONIMO-3887 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > Attachments: GERONIMO-3887-2.patch, GERONIMO-3887.patch > > > The plugin installer located in the administration console fails to install > new plugins once it runs into an install that throws an exception for being > the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
[ https://issues.apache.org/jira/browse/GERONIMO-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3887: --- Patch Info: [Patch Available] > After installing with wrong configuration unable to proceed with any new > plugin installs > > > Key: GERONIMO-3887 > URL: https://issues.apache.org/jira/browse/GERONIMO-3887 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > Attachments: GERONIMO-3887.patch > > > The plugin installer located in the administration console fails to install > new plugins once it runs into an install that throws an exception for being > the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3939) Failing to start plugin after install if previous plugin install failed.
[ https://issues.apache.org/jira/browse/GERONIMO-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582400#action_12582400 ] Joseph Leong commented on GERONIMO-3939: The resolution for this issue has been consolidated into the patch posted at GERONIMO-3887 ! Please refer to that JIRA for further updates regarding the two issues. -Joseph Leong > Failing to start plugin after install if previous plugin install failed. > > > Key: GERONIMO-3939 > URL: https://issues.apache.org/jira/browse/GERONIMO-3939 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 > Environment: Ubuntu 7.10, Firefox >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > > The admin console plugin installer fails to start a plugin after install > under the condition that a previous plugin install failed. > The plugin installer is hung on the cache of the previous failed install and > won't start or show the progress of the new plugin install. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
[ https://issues.apache.org/jira/browse/GERONIMO-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3887: --- Attachment: GERONIMO-3887.patch Patch posted. This patch also resolves issue mentioned in GERONIMO-3939 > After installing with wrong configuration unable to proceed with any new > plugin installs > > > Key: GERONIMO-3887 > URL: https://issues.apache.org/jira/browse/GERONIMO-3887 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > Attachments: GERONIMO-3887.patch > > > The plugin installer located in the administration console fails to install > new plugins once it runs into an install that throws an exception for being > the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
[ https://issues.apache.org/jira/browse/GERONIMO-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582296#action_12582296 ] Joseph Leong commented on GERONIMO-3887: I'll take a look at the setLoad. Right now i'm using the uninstallconfiguration(artifact) which is the procedure used to remove obsolete artifacts. I'll look further into the method to see what that entails. Thus far it seems to solve the starting issue, it seems to remove any remnants of the first failed install when starting the second plugin. I'll keep everyone updated. Joseph Leong > After installing with wrong configuration unable to proceed with any new > plugin installs > > > Key: GERONIMO-3887 > URL: https://issues.apache.org/jira/browse/GERONIMO-3887 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 > Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > > The plugin installer located in the administration console fails to install > new plugins once it runs into an install that throws an exception for being > the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
[ https://issues.apache.org/jira/browse/GERONIMO-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582057#action_12582057 ] Joseph Leong commented on GERONIMO-3887: Update: Ok good news, so rather than doing a filter on the higher level to prevent users from installing misconfigurations. I am attacking the core of the problem as it will solve more issues later. So after further inspect, i can confirm what is happening. The PluginInstallerGbean has no clean up procedure for if it it fails to install a plugin. It will just set the downloadresult failure to true and make a log of it. So the issue is hanging. Approach to resolution: In the PluginInstallerGBean , i've created an artifact list to keep track of the history of dependencies and pieces that are being downloaded/installed . Upon catching an exception for failure to start the artifact it will perform the cleanup routine and uninstall the artifacts that is included in that plugin. Thus far results looks promising.. further testing to confirm and a new patch to be posted soon. -Joseph Leong > After installing with wrong configuration unable to proceed with any new > plugin installs > > > Key: GERONIMO-3887 > URL: https://issues.apache.org/jira/browse/GERONIMO-3887 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > > The plugin installer located in the administration console fails to install > new plugins once it runs into an install that throws an exception for being > the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3939) Failing to start plugin after install if previous plugin install failed.
Failing to start plugin after install if previous plugin install failed. Key: GERONIMO-3939 URL: https://issues.apache.org/jira/browse/GERONIMO-3939 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Environment: Ubuntu 7.10, Firefox Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1.1, 2.2 The admin console plugin installer fails to start a plugin after install under the condition that a previous plugin install failed. The plugin installer is hung on the cache of the previous failed install and won't start or show the progress of the new plugin install. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
[ https://issues.apache.org/jira/browse/GERONIMO-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581641#action_12581641 ] Joseph Leong commented on GERONIMO-3887: Further inspection has spawned the following approach: The first approach was to ensure that the prereq description was correctly defined. However, the prereq description is not appropriate for preventing the installation of jetty plugins on tomcat containers and vise versa. Reason being we want the flexibility to start with any framework and install a plugin of a certain container without explicitly instaling that container. The second approach is to make the plugins more transactional. That is if something were to go wrong, a complete rollback of the plugin install can be performed. Factors to consider is that there will need to be a temporary copy of the original config state and a list of everything we put in the repo. However, the issue with this is that we aren't currently preserving the original state of the config files.. and often times the specific files are in the implementation details and not a general set. Lastly, and the strongest approach that i am learning towards, is creating something on a higher layer. Keep in mind this solution will help solve the issue in the administrative console but, will have to be dealt with seperately if it occurs in say.. GShell. This feature in the admin console would hide plugins that match a certain regex.. say.. if we're in a Tomcat deployment.. hides or disables the Jetty options. In conclusion there is no good constraint implementation curretly in place. Please feel free to review the three options above and certainly contribute any ideas you my have. I plan to implement the third one as of now.. Progress will be posted. Thanks! -Joseph Leong > After installing with wrong configuration unable to proceed with any new > plugin installs > > > Key: GERONIMO-3887 > URL: https://issues.apache.org/jira/browse/GERONIMO-3887 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > > The plugin installer located in the administration console fails to install > new plugins once it runs into an install that throws an exception for being > the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
[ https://issues.apache.org/jira/browse/GERONIMO-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581097#action_12581097 ] Joseph Leong commented on GERONIMO-3887: Investigating the Lifecycle Exception and Misconfiguration Exception to see what is causing it from continuing afterwards. > After installing with wrong configuration unable to proceed with any new > plugin installs > > > Key: GERONIMO-3887 > URL: https://issues.apache.org/jira/browse/GERONIMO-3887 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1, 2.2 > > > The plugin installer located in the administration console fails to install > new plugins once it runs into an install that throws an exception for being > the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3856: --- Patch Info: [Patch Available] > Assemble a Server Confirmation Page > --- > > Key: GERONIMO-3856 > URL: https://issues.apache.org/jira/browse/GERONIMO-3856 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 > Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-3856.patch > > > Improvements for the Assemble a Server Confirmation Page > 1) At minimum the user should provide an artifact id otherwise assembly named > --bin.tar.gz will be created. The portlet should check for empty artifact id. > 2) If no plugins are selected and 'assemble' button is pressed a nasty > exception will be displayed. The portlet should check if at least one plugin > was selected. > 3) On the confirmation screen and on Windows the server path location will > contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3856: --- Attachment: GERONIMO-3856.patch Patch Available! 1) At minimum the user should provide an artifact id otherwise assembly named --bin.tar.gz will be created. The portlet should check for empty artifact id. Soln: Javascript check provided to ensure artifact id is filled. 2) If no plugins are selected and 'assemble' button is pressed a nasty exception will be displayed. The portlet should check if at least one plugin was selected. Soln: Javascript check provided to ensure at least one plugin is checked. 3) On the confirmation screen and on Windows the server path location will contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. Soln: OS Detection. Depending if OS was window's setup the initial assembly path as well as relativepath with correct slash format. > Assemble a Server Confirmation Page > --- > > Key: GERONIMO-3856 > URL: https://issues.apache.org/jira/browse/GERONIMO-3856 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 > Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-3856.patch > > > Improvements for the Assemble a Server Confirmation Page > 1) At minimum the user should provide an artifact id otherwise assembly named > --bin.tar.gz will be created. The portlet should check for empty artifact id. > 2) If no plugins are selected and 'assemble' button is pressed a nasty > exception will be displayed. The portlet should check if at least one plugin > was selected. > 3) On the confirmation screen and on Windows the server path location will > contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579585#action_12579585 ] Joseph Leong commented on GERONIMO-3856: Testing patch on a windows deployed AG to verify 3) before posting patch. -Joseph Leong > Assemble a Server Confirmation Page > --- > > Key: GERONIMO-3856 > URL: https://issues.apache.org/jira/browse/GERONIMO-3856 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > > Improvements for the Assemble a Server Confirmation Page > 1) At minimum the user should provide an artifact id otherwise assembly named > --bin.tar.gz will be created. The portlet should check for empty artifact id. > 2) If no plugins are selected and 'assemble' button is pressed a nasty > exception will be displayed. The portlet should check if at least one plugin > was selected. > 3) On the confirmation screen and on Windows the server path location will > contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578868#action_12578868 ] Joseph Leong commented on GERONIMO-3856: Progress: Patch will be provided shortly. 1) Javascript check added 2) Javascript added to perform check for plugin to prevent rendering null value 500 error. 3) Using system getproperty and if windows machine, changing initial path slash value to correct format and passing that all the way through to the absolutepath displayed at the confirmation page. -Joseph Leong > Assemble a Server Confirmation Page > --- > > Key: GERONIMO-3856 > URL: https://issues.apache.org/jira/browse/GERONIMO-3856 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > > Improvements for the Assemble a Server Confirmation Page > 1) At minimum the user should provide an artifact id otherwise assembly named > --bin.tar.gz will be created. The portlet should check for empty artifact id. > 2) If no plugins are selected and 'assemble' button is pressed a nasty > exception will be displayed. The portlet should check if at least one plugin > was selected. > 3) On the confirmation screen and on Windows the server path location will > contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578408#action_12578408 ] Joseph Leong commented on GERONIMO-3856: Progress: 1) Javascript check added 2) Javascript added to perform check for plugin to prevent rendering null value 500 error. 3) Working on it.. will need to determine if running on a windows / *nix based machine and change path location accordingly > Assemble a Server Confirmation Page > --- > > Key: GERONIMO-3856 > URL: https://issues.apache.org/jira/browse/GERONIMO-3856 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > > Improvements for the Assemble a Server Confirmation Page > 1) At minimum the user should provide an artifact id otherwise assembly named > --bin.tar.gz will be created. The portlet should check for empty artifact id. > 2) If no plugins are selected and 'assemble' button is pressed a nasty > exception will be displayed. The portlet should check if at least one plugin > was selected. > 3) On the confirmation screen and on Windows the server path location will > contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578383#action_12578383 ] Joseph Leong commented on GERONIMO-3856: Progress: 1) Working on it... 2) Javascript added to perform check for plugin to prevent rendering null value 500 error. 3) Working on it.. will need to determine if running on a windows / *nix based machine and change path location accordingly > Assemble a Server Confirmation Page > --- > > Key: GERONIMO-3856 > URL: https://issues.apache.org/jira/browse/GERONIMO-3856 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1, 2.2 >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > > Improvements for the Assemble a Server Confirmation Page > 1) At minimum the user should provide an artifact id otherwise assembly named > --bin.tar.gz will be created. The portlet should check for empty artifact id. > 2) If no plugins are selected and 'assemble' button is pressed a nasty > exception will be displayed. The portlet should check if at least one plugin > was selected. > 3) On the confirmation screen and on Windows the server path location will > contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578046#action_12578046 ] Joseph Leong commented on GERONIMO-3893: Silly me.. implemented.. Patch 2.. Thanks Jarek -Joseph Leong > When installing plugins, exception thrown when no plugins selected > -- > > Key: GERONIMO-3893 > URL: https://issues.apache.org/jira/browse/GERONIMO-3893 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1 >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Fix For: 2.1.1 > > Attachments: GERONIMO-3893-2.patch, GERONIMO-3893.patch > > > In the administration console->plugin installer. When trying to install > plugins, If no plugins are selected (check box), an exception is thrown and a > 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Attachment: GERONIMO-3893-2.patch > When installing plugins, exception thrown when no plugins selected > -- > > Key: GERONIMO-3893 > URL: https://issues.apache.org/jira/browse/GERONIMO-3893 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1 > Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Fix For: 2.1.1 > > Attachments: GERONIMO-3893-2.patch, GERONIMO-3893.patch > > > In the administration console->plugin installer. When trying to install > plugins, If no plugins are selected (check box), an exception is thrown and a > 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578036#action_12578036 ] Joseph Leong commented on GERONIMO-3781: As far as I know I haven't implemented any changes for this yet, still working on it. > Plugin Installer, CRSF issue when attempting to install a new plugin > > > Key: GERONIMO-3781 > URL: https://issues.apache.org/jira/browse/GERONIMO-3781 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1 > Environment: Ubuntu 7.10, Firefox 2.0.0.6 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1 > > > Plugin installer will not allow for you to install anymore plugins on a > second attempt given that it threw an exception the first time. This is > attributed to the exception thrown that doesn't properly exit and close off > current sessions. So in the second attempt there is a cookie/session > mismatch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Affects Version/s: 2.1.1 Fix Version/s: 2.1.1 > When installing plugins, exception thrown when no plugins selected > -- > > Key: GERONIMO-3893 > URL: https://issues.apache.org/jira/browse/GERONIMO-3893 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1 > Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Fix For: 2.1.1 > > Attachments: GERONIMO-3893.patch > > > In the administration console->plugin installer. When trying to install > plugins, If no plugins are selected (check box), an exception is thrown and a > 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Patch Info: [Patch Available] > When installing plugins, exception thrown when no plugins selected > -- > > Key: GERONIMO-3893 > URL: https://issues.apache.org/jira/browse/GERONIMO-3893 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 > Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-3893.patch > > > In the administration console->plugin installer. When trying to install > plugins, If no plugins are selected (check box), an exception is thrown and a > 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Attachment: GERONIMO-3893.patch Javascript added to check whether a plugin box is checked before submitting to prevent 500 render error. > When installing plugins, exception thrown when no plugins selected > -- > > Key: GERONIMO-3893 > URL: https://issues.apache.org/jira/browse/GERONIMO-3893 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 > Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > Attachments: GERONIMO-3893.patch > > > In the administration console->plugin installer. When trying to install > plugins, If no plugins are selected (check box), an exception is thrown and a > 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577959#action_12577959 ] Joseph Leong commented on GERONIMO-3893: Implemented Javascript to ensure one item is at least checked before rendering parameters to prevent from the 500 error. Patch will be posted shortly! -Joseph Leong > When installing plugins, exception thrown when no plugins selected > -- > > Key: GERONIMO-3893 > URL: https://issues.apache.org/jira/browse/GERONIMO-3893 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > > In the administration console->plugin installer. When trying to install > plugins, If no plugins are selected (check box), an exception is thrown and a > 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
[ https://issues.apache.org/jira/browse/GERONIMO-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3893: --- Description: In the administration console->plugin installer. When trying to install plugins, If no plugins are selected (check box), an exception is thrown and a 500 error occurs. (was: If no plugins are selected (check box) to be installed, an exception is thrown and a 500 error occurs.) > When installing plugins, exception thrown when no plugins selected > -- > > Key: GERONIMO-3893 > URL: https://issues.apache.org/jira/browse/GERONIMO-3893 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1 >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > > In the administration console->plugin installer. When trying to install > plugins, If no plugins are selected (check box), an exception is thrown and a > 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3893) When installing plugins, exception thrown when no plugins selected
When installing plugins, exception thrown when no plugins selected -- Key: GERONIMO-3893 URL: https://issues.apache.org/jira/browse/GERONIMO-3893 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor If no plugins are selected (check box) to be installed, an exception is thrown and a 500 error occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
After installing with wrong configuration unable to proceed with any new plugin installs Key: GERONIMO-3887 URL: https://issues.apache.org/jira/browse/GERONIMO-3887 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong The plugin installer located in the administration console fails to install new plugins once it runs into an install that throws an exception for being the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Remove children pages AG2.1->Tools and Commands... Confluence, no access
Hi everyone, If someone with the correct privileges could remove the following children pages from the AG2.1 Tools and commands: -client.jar -deploy -Deployer tool -geronimo -jpa.jar -shutdown -startup In light of our discussion about reducing tree hierarchy for a less tedious navigation system, these children pages were compact enough to appropriately represent them as anchors on the root page of Tools and commands. Thanks! I will be integrating it into the root page now. -Joseph Leong
Remove some 2.1 children pages, not enough access
In the 2.1 documentation, rather than creating children pages for the bullet points under the Geronimo Administration Console - i've appropriately integrated them into the Geronimo Administration Console root page. So if someone with the correct access privilege could please remove the following children pages in 2.1: CA helper <http://cwiki.apache.org/confluence/display/GMOxDOC21/CA+helper> (Apache Geronimo v2.1) Console enhancements<http://cwiki.apache.org/confluence/display/GMOxDOC21/Console+enhancements> (Apache Geronimo v2.1) Deployment plans wizard<http://cwiki.apache.org/confluence/display/GMOxDOC21/Deployment+plans+wizard> (Apache Geronimo v2.1) Expert mode<http://cwiki.apache.org/confluence/display/GMOxDOC21/Expert+mode> (Apache Geronimo v2.1) The pluggable console<http://cwiki.apache.org/confluence/display/GMOxDOC21/The+pluggable+console> (Apache Geronimo v2.1) What Changed?<http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=77772> (Apache Geronimo v2.1) Thanks! Joseph Leong
[jira] Commented: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573107#action_12573107 ] Joseph Leong commented on GERONIMO-3781: Hey Jarek, Great! Beat me too it, ya i saw that in Manu's response and a light bulb went off. I'll verify it and follow up with this Jetty issue. Thanks Jarek -Joseph Leong > Plugin Installer, CRSF issue when attempting to install a new plugin > > > Key: GERONIMO-3781 > URL: https://issues.apache.org/jira/browse/GERONIMO-3781 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1, 2.1.1 > Environment: Ubuntu 7.10, Firefox 2.0.0.6 >Reporter: Joseph Leong >Assignee: Joseph Leong > Fix For: 2.1.1 > > > Plugin installer will not allow for you to install anymore plugins on a > second attempt given that it threw an exception the first time. This is > attributed to the exception thrown that doesn't properly exit and close off > current sessions. So in the second attempt there is a cookie/session > mismatch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Regarding SSO across admin console
Hi Manu, As Kevan mentioned - I ran into a similar issue as well while working on the plugin installer in console. But I can't say it better than Joe Bohn (above), the issue rooted from the JSessionID getting corrupted. So the first suggestion would be to verify whether the JSessionID is getting corrupted or deleted. Let us know what ya find and hopefully we can step through this. Which portlet is this for? -Joseph Leong On Wed, Feb 27, 2008 at 12:19 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: > Manu George wrote: > > Hi, > >I added a new portlet to the admin console via the newHi > > pluggable mechanism. However when I click on the link to that portlet > > I am always asked to authenticate even though I have authenticated on > > the login page of the admin console. How can I configure my portlet to > > also be part of the single sign on across the admin console. > > > > Regards > > Manu > > > > Hi Manu, > > I don't know the answer but here are some things you can investigate: > > 1) I know that we had issues with this and the pluggable console > earlier with Jetty. I thought those issues were resolved but if you are > using Jetty you might want to give Tomcat a try. > > 2) The problem you describe typically happens with the portlet session > gets corrupted/reset or when the JSessionID cookie gets > corrupted/deleted. You might want to check if you are doing anything > special that might affect the session. > > Finally, the doc that Kevan referenced includes a sample. You might > want to try that sample first and then begin adding in your specifics > until the problem surfaces. > > Joe Bohn > >
[jira] Commented: (GERONIMO-3867) Export Plugin in Web Console results in NullPointerException if no component is selected
[ https://issues.apache.org/jira/browse/GERONIMO-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573040#action_12573040 ] Joseph Leong commented on GERONIMO-3867: Great, thanks for the heads up Joe. I'll be resuming work then in this plugin-portlet section then - for your reference so i don't clash with your work you can refer to: GERONIMO-3781, GERONIMO-3856 and GERONIMO-3868 for updates. -Joseph Leong > Export Plugin in Web Console results in NullPointerException if no component > is selected > > > Key: GERONIMO-3867 > URL: https://issues.apache.org/jira/browse/GERONIMO-3867 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.1 >Reporter: Joe Bohn >Assignee: Joe Bohn > > When attempting to export a component as a plugin in the web console a NPE is > thrown is no component is selected (actually, a NPE is thrown even if a > component is selected but that is another issue, GERONIMO-3866). We should > check to validate that a component is selected in the JSP. > 16:19:37,170 ERROR [MultiPagePortlet] Unable to render portlet > java.lang.NullPointerException > at > org.apache.geronimo.console.car.ExportConfigHandler.renderView(ExportConfigHandler.java:71) > at > org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:144) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) > at > org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) > at > org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) > at > org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) > at > org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) > at > jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) > at > org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) > at > jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) > at > jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445) > at > org
[jira] Commented: (GERONIMO-3867) Export Plugin in Web Console results in NullPointerException if no component is selected
[ https://issues.apache.org/jira/browse/GERONIMO-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572642#action_12572642 ] Joseph Leong commented on GERONIMO-3867: Hi Joe, Any ideas as to which files you'll be modifying for this piece. I've been kind of tip toeing around the JIRA's i have open that are in the plugin installer because i didn't want to clash with your work. Or if we work concurrently, perhaps you'd like to review my patches so it doesn't clash with your designs? Thanks! -Joseph Leong > Export Plugin in Web Console results in NullPointerException if no component > is selected > > > Key: GERONIMO-3867 > URL: https://issues.apache.org/jira/browse/GERONIMO-3867 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.1 >Reporter: Joe Bohn >Assignee: Joe Bohn > > When attempting to export a component as a plugin in the web console a NPE is > thrown is no component is selected (actually, a NPE is thrown even if a > component is selected but that is another issue, GERONIMO-3866). We should > check to validate that a component is selected in the JSP. > 16:19:37,170 ERROR [MultiPagePortlet] Unable to render portlet > java.lang.NullPointerException > at > org.apache.geronimo.console.car.ExportConfigHandler.renderView(ExportConfigHandler.java:71) > at > org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:144) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) > at > org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) > at > org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) > at > org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) > at > org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) > at > jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481) > at > org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) > at > jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) > at > jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) > at > o
Re: Too many levels of menu before content in docs?
Hi All, To reduce the number of layers... any thoughts on implementing a page that encompasses the main subject with well defined heading hierarchy then referencing using page + anchors? I recognize that for some documentation (administrative tasks...) this would yield an excessively long page - but with the right combination we may be able to reduce quite a few levels? Also, i like the tree idea Jason and David mentioned above. Wishing you all the best, Joseph Leong On Tue, Feb 26, 2008 at 1:49 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > I liked David's idea of collapsible trees. Is that possible with the > wiki? It doesn't seem like something a wiki would be able to inherently > handle but one can hope. > > > On Tue, Feb 26, 2008 at 1:41 PM, Hernan Cunico <[EMAIL PROTECTED]> wrote: > > > Dave, > > we need to figure out a way to organize th content. For 2.1 we'll > > hopefully end up around 200 pages, we can't have them all listed on one > > page. > > > > More specifically on "Installing and removing applications" it will only > > take 2 clicks to get there once in the 2.1 doc space > > > > From http://cwiki.apache.org/GMOxDOC21/documentation.html click on > > *Administration* and then on *Installing and removing applications*. The > > breadcrumbs help navigate through the hierarchy, a user will not necessarily > > have to navigate through every single one of those topics to get to the > > content wanted. > > > > On the 2.1 doc home page we definitively need to show a subset of > > topics, I think a 3 level (as we have it now) is OK. Maybe lower it to just > > 2 levels if we rework the titles and rearrange the structure. > > > > What do others think? > > > > Cheers! > > Hernan > > > > David Jencks wrote: > > > This seems a wee bit excessive to me... > > > > > > ...Documentation > Administration > Administrative Tasks > > > Administering > > > applications > Installing and removing applications > > > > > > Can we get expandable trees in the Documentation page? If so I think > > > the links on Documentation should take you directly to documentation > > > > > > If not I'd be happier with a maximum of 1 layer of additional menus > > > > > > thanks > > > david jencks > > > > > > > > > -- > ~Jason Warner
Re: Geronimo v2.1 documentation update
I'm glad the question has been brought up, i was wondering myself... Ditto above Also, for the sections that are in 2.0 users that are not on 2.1 users - does this mean we have decided to not transfer these sections over? (i.e. some of the sample applications) or is it because some of the documentation outline for 2.1 is not complete yet. Wishing you all the best, Joseph Leong On Fri, Feb 22, 2008 at 2:09 PM, Dan Becker <[EMAIL PROTECTED]> wrote: > Jason Warner wrote: > > What's the "need update" column for on the 2.0 Update status page? Is > that > > to mark a page that is moved over but still needs someone who knows what > the > > article is talking about to update it based on 2.1? > > Good question. I've been treating it as "needs rework to move to 2.1" > for planning purposes, but I agree this column can have many meanings. > An official statement would be helpful. > -- > Thanks, Dan Becker > email: mailto://[EMAIL PROTECTED] >
[jira] Commented: (GERONIMO-3868) Plugin Installer Portlet Over Cluttered
[ https://issues.apache.org/jira/browse/GERONIMO-3868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571302#action_12571302 ] Joseph Leong commented on GERONIMO-3868: Thanks Paul! I was looking for a good piece of reference. -Joe Leong > Plugin Installer Portlet Over Cluttered > --- > > Key: GERONIMO-3868 > URL: https://issues.apache.org/jira/browse/GERONIMO-3868 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Reporter: Joseph Leong >Assignee: Joseph Leong >Priority: Minor > > The plugin-portlet piece is over cluttered by having too many function and it > would be beneficial to split up the respective pieces (plugin installer, > export a plugin, and assemble a server) into it's own pieces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
