I'll review these documents, as this should no longer be necessary.
- Brett
On 01/03/2007, at 1:44 AM, Thierry Lach wrote:
I'm very much in favor of being able to download a war or an ear
and drop it
in place.
But...
So far some of the instructions that I've seen make a "download-and-
ins
My thoughts almost exactly. Any changes that need to be made under the
build-from-source approach should be able to be applied as patches or as a
configuration file.
On 2/28/07, Hilco Wijbenga <[EMAIL PROTECTED]> wrote:
On 2/28/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
> I'm very much in fav
On 2/28/07, Thierry Lach <[EMAIL PROTECTED]> wrote:
I'm very much in favor of being able to download a war or an ear and drop it
in place.
I'd like to second that. A "drop-and-forget" install, as it were. :-)
The closer we can get to that, the better (even if that means limiting
the app servers
I'm very much in favor of being able to download a war or an ear and drop it
in place.
But...
So far some of the instructions that I've seen make a "download-and-install"
approach difficult.
For example, changing the application name and email subject line require
editing a plexus configuration
We should be able support anything people can test and document.
The best tested will probably remain the plexus app server and/or
jetty, using derby.
- Brett
On 01/03/2007, at 12:41 AM, Hilco Wijbenga wrote:
On 2/28/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
users download the war fi
On 2/28/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
users download the war file and deploy it, they can use the standalone app too.
Is the WAR expected to run on any app server? Or are we going to
support a specific app server? Or a few?
What about databases? Are we going to assume Derby?
I'm trying to go into Administration Appearance logged in as my default
admin. It asks me to log in (even though I am already there) and then takes
me to groupSummary, not appearance. This worked properly yesterday.
Why is that the 'correct' method?
In Struts 2.0, doInput has been removed in favour of input (rather,
do* replaced by * in the general case).
- Brett
On 28/02/2007, at 11:41 PM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Wed Feb 28 07:41:36 2007
New Revision: 512813
URL: http://svn.a
Some problems here.
You can't extend JdoUserManager.
That won't work.
If you need multiple sources for Users, then that is a feature we need
to add to the security framework.
We already do this with the Authorization bits. I see no reason we
can't do that for the Authentication bits too.
Again,
Andrew Williams wrote:
OK, not entirely sure what to do about this problem now...
Calling getBuildResultsForProject over RPC yields this exception on the
server side.
Caused by: javax.jdo.JDODetachedFieldAccessException: You have just
attempted to access field "modifiedDependencies" yet this
OK, not entirely sure what to do about this problem now...
Calling getBuildResultsForProject over RPC yields this exception on
the server side.
Caused by: javax.jdo.JDODetachedFieldAccessException: You have just
attempted to access field "modifiedDependencies" yet this field was
not detac
Hi,
at first thanks for your help. I want to write a UserManager, which
extends the JdoUserManager and only search in LDAP if the user isn't
saved in Database.
But my first problem is that I don't understand, how continuum knows
that it should use my UserManager-implementation.
- David
Joakim E
users download the war file and deploy it, they can use the standalone app too.
Emmanuel
Thierry Lach a écrit :
What is/will be the installation/deployment approach for continuum? Will
users be able to download a war file and deploy it? Or will users always
have to build from source?
13 matches
Mail list logo
