Re. hosting it on localhost, maybe we should put the "friendly" changelog on the localhost. And even provide a link from the login page and once logged in the welcome page.
This changelog can then document everything that changed, including things that make your life easier, changes in behaviour (like the problem we're discussing), changes in UI (things that are added/moved/removed), etc. It makes it more accessible, and errors like this one can refer to it. Then further, anything on the console that's new can have a little [*] link next to it, which links to it's item in the changelog. Q On Fri, Sep 11, 2009 at 3:04 PM, Quintin Beukes <quin...@skywalk.co.za> wrote: > Sorry, missed the message. > > As I suggested on the > ticket(https://issues.apache.org/jira/browse/GERONIMO-4867), that a > good default for an "absent" option is to have it global. Which is the > same behaviour as previously. > > A problem with documentation is that people don't always read the > "upgrade docs" before the "upgrade". it's good practice, but rarely > done, and one should try and make all user's experiences comfortable. > > I think doing all the following should do the trick. They are changes > in UI as well as behaviour. People get used to doing things in a > certain way, and if they do their 'things' and it doesn't work, sure > it's their fault but it still makes their life more difficult and > their experience of Geronimo more unpleasant. Successful software > usually design around these points of failure to provide for all kinds > of users/situations so their experiences are more of a smooth ride. > Further, to make it more clear what has gone wrong when it DOES happen > (like when they use a deployment plan which worked perfectly with > Geronimo 2.1), the following helps out with that as well. > > - Purely when the attribute is absent, thus NULL (compared to > true/false), fail the deploy (required attribute) and show a message > similar to the following: "Since Geronimo 2.2, the 'global' realm > attribute is required. See > <http://localhost:8080/console/global-attribute-update.html> for > details". I think hosting it in the localhost helps for those people > who deploy in situations where they don't have the internet. Rare? > Even necessary? It does happen though. I've done deployments 3KM > underground, and then you are very far away from the net. > - When you try to connect to a realm which exists, but is not global, > don't show "No LoginModules defined", rather say something like "Realm > 'mySecurityRealm' is not global" > - When creating a security realm through the console, move the > "Global" option to the top of the list (it helps it being noticed). > Alternatively add a *new to it (which might look a bit corny). > - How about branching out from the start. Instead of doing an "Add New > Security Realm" on the realms listing, split it into 2 options, ie. > "Add new Local Realm", "Add new Global Realm". > > Q > > On Thu, Sep 10, 2009 at 8:34 PM, Juergen Weber <webe...@gmail.com> wrote: >> >> What about a hint in the Exception message? This is the first thing one reads >> if something goes wrong, much earlier than documentation. >> >> Greetings, Juergen >> >> >> >> djencks wrote: >>> >>> That's certainly a danger. Do you think we could solve this with >>> documentation? The non-global realms interfere less with each other >>> so I think they make a better default. Any other opinions? >>> >>> thanks >>> david jencks >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Possible-Bug-in-Geronimo-when-doing-remote-login-with-OpenEJB--RemoteInitialContextFactory-tp25382312s134p25388718.html >> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com. >> >> > > > > -- > Quintin Beukes > -- Quintin Beukes
