Well, depending on what we mean by "command", it should be feasible, i.e. if we mean a "method" of some class. And if we're talking about a command as in the commands configured in admin central, if that makes sense, it should be possible to wrap the call in a groovy class as well.
1) Create a groovy class. It'll be seen as any regular java class by the system.
2) Expose said class to freemarker via sharedVariables (cfr our freemarker doc, I assume)
3) …
4) Profit !

Hi,

If you copy your jsp file in the *correct* location, it *should* be picked up, but that entirely depends on your container. Tomcat should pickup changes by default. Magnolia has nothing to do with that.

You'll also need to replicate the changes to *both* author and public instances if you want them to appear on both sides. Activation only pushes the *content*. If you used FreeMarker, you'd be able to have templates in the repository, thus they'd be activatable as well, but that's not the case with JSP out-of-the-box (there's a module for this, but I'm afraid it would confuse you more than anything right now)

Please seek further help in the forum: http://forum.magnolia-cms.com and keep the comment section of the documentation for comments *about* the documentation itself :) Thanks and good luck !

Aditi, this is symptomatic of a broken installation. Can you check your application server logs, as well as Magnolia's ?
Which application server are you using, and which Magnolia edition/packaging/version ?

Perhaps try http://localhost:8080 ... but I guess if http://127.0.0.1:8080/ can't be reached, it's simply because something went wrong during startup.. and the server wasn't started ? Can you have a look at the log files ?

Cool, glad you like what you see.

You can, and that's what you'll end up doing on a production system, most likely. These instructions are directed at less technically-savyy users, I guess, evaluating Magnolia for the first time, and not necessarily aware of all Java/Tomcat quirks.

The proper, current, way would be ModuleRegistry.Factory.getInstance().getModuleInstance(<moduleClass-or-name>)
With Magnolia 5 and the introduction of IoC, any component will be able to declare a dependency to "YourModuleClass", via their constructor, for instance.

lack of permissions. If you need the user to login to AdminCentral, it will need permissions to the config workspace (at the very least to see the menu - start with read only on all /), get/post on /* (including /.magnolia*), and permissions to the workspace you need this user to edit.

That depends entirely on the repository implementation. In the case of JackRabbit (the repo impl we ship with Magnolia by default), you can use a db, or just the filesystem, or any other storage mechanism you could think of it. We provide a few default configuration to work with mysql, oracle, ... or derby, the java embedded db, by default (not recommend for production)

Also, why do we "recommend Subversion for Windows", whereas everyone on windows that I've seen uses tortoise (when not using the client built in the IDE, that is)