My guess is that it's a corrupt database problem and there's an exception
being thrown during the processing of Boot.scala

If you've got two apps on the same app server and they are both using Derby,
it's likely that they are trying to share the same Derby files which is
causing the corruption.

So... take at look at std.out and std.err and look for Exceptions during
Boot.scala.

On Mon, Jul 6, 2009 at 5:22 AM, Kevin Wright
<kev.lee.wri...@googlemail.com>wrote:

> I did see this problem running on localhost on my windows box at home.
> Not tried removing the DB yet, although that is scheduled to go.
>
>
>
>
> On Mon, Jul 6, 2009 at 1:20 PM, marius d. <marius.dan...@gmail.com> wrote:
>
>>
>> Still ... we need to get to the bottom of this ... I made a dummy app
>> and deploy it under main.war and stage.war ... again everything works
>> correctly (I'm on Windows currently).
>>
>> Can you make a minimalistic app (with no DB) where this problem
>> reproduces and send it over? ... Can you reproduce this on you
>> localhost tomcat?
>>
>> Br's,
>> Marius
>>
>> On Jul 6, 3:13 pm, Kevin Wright <kev.lee.wri...@googlemail.com> wrote:
>> > Thanks for your ongoing efforts :)
>> >
>> > If you want to test with the LSUG app, feel free to grab it from github:
>> http://github.com/kevinwright/lsug-website/tree/master
>> >
>> > Just to clarify, I'm working with continuous deplyment here.  The stage
>> site
>> > gets auto-deployed following a successful hudson build (and hudson is in
>> > turn triggered by changes to the underlying source code).  If no
>> problems
>> > exist in staging then I can very quickly promote it to the main site (by
>> > copying the war)
>> >
>> > I really don't want to have any differences between the two apps (such
>> as
>> > package names), I don't even want for them to be produced by different
>> > builds against the same source as this defeats much of the point in
>> running
>> > staged deployments.
>> >
>> > Although it isn't so vital for LSUG, If I'm to successfully evangelise
>> Lift
>> > to my employers then I also need for this pattern to work on commercial
>> > sites, where it is much more important that I can guarantee the
>> production
>> > site is identical to the site that passed user testing...
>> >
>> > On Mon, Jul 6, 2009 at 1:02 PM, marius d. <marius.dan...@gmail.com>
>> wrote:
>> >
>> > > Well I just deployed 2 different Lift apps in jetty and everything is
>> > > working fine.
>> >
>> > > Here is wild thought.... can you try changing the package names. I
>> > > know it shouldn't matter but this is an awkward case still.
>> >
>> > > Br's,
>> > > Marius
>> >
>> > > On Jul 6, 2:32 pm, Kevin Wright <kev.lee.wri...@googlemail.com>
>> wrote:
>> > > > I agree with your thinking that this looks like a classloading
>> issue, but
>> > > > haven't (yet) tried any clever optimisations here :)
>> > > > The only shared jars are those supplied by default via java/tomcat.
>>  When
>> > > I
>> > > > get a moment though, it might be worth checking for the usual
>> culprits
>> > > > (commons-logging, etc).
>> >
>> > > > I didn't try to read back the sitemap in my code, it's just two
>> > > statically
>> > > > defined locs (see the source on github).  I can certainly attempt
>> the
>> > > > readback for troubleshooting purposes, but still not sure how this
>> can
>> > > help
>> > > > us track down the issue if it fails...
>> >
>> > > > Context paths are not explicitly set, no custom context.xml files,
>> > > nothing
>> > > > special in tomcat whatsoever - the two war files are auto-deployed
>> and
>> > > are
>> > > > identical (apart from their names, obviously)
>> >
>> > > > On Mon, Jul 6, 2009 at 12:18 PM, marius d. <marius.dan...@gmail.com
>> >
>> > > wrote:
>> >
>> > > > > Oh btw. did you explicitly set the context path for each app ?
>> >
>> > > > > On Jul 6, 2:09 pm, "marius d." <marius.dan...@gmail.com> wrote:
>> > > > > > Looks like there is an "influence" there but it should really
>> not be
>> > > > > > since each web application is loaded by a separate classloader.
>> >
>> > > > > > 1. Do you have any jars that these webapps are sharing?
>> > > > > > 2. If you put some logs in Boot do you see the logs correctly?
>> ... If
>> > > > > > you call LiftRules.siteMap after you set the siteMap gdo you get
>> back
>> > > > > > the right SiteMap ?
>> >
>> > > > > > Br's,
>> > > > > > Marius
>> >
>> > > > > > On Jul 6, 1:35 pm, Kevin Wright <kev.lee.wri...@googlemail.com>
>> > > wrote:
>> >
>> > > > > > > Marius, should I be thinking that you have a theory on this
>> one?
>> >
>> > > > > > > On Mon, Jul 6, 2009 at 9:55 AM, Kevin Wright
>> > > > > > > <kev.lee.wri...@googlemail.com>wrote:
>> >
>> > > > > > > > Interesting... yes it does
>> >
>> > > > > > > > On Mon, Jul 6, 2009 at 9:51 AM, marius d. <
>> > > marius.dan...@gmail.com>
>> > > > > wrote:
>> >
>> > > > > > > >> And if you deploy onlyhttp://lsug.org/main/doesit work
>> > > correctly?
>> >
>> > > > > > > >> Br's,
>> > > > > > > >> Marius
>> >
>> > > > > > > >> On Jul 6, 10:17 am, Kevin Wright <
>> kev.lee.wri...@googlemail.com
>> >
>> > > > > > > >> wrote:
>> > > > > > > >> > I have two webapps, hosted on the same server:
>> > > > > > > >>http://lsug.org/main/http://lsug.org/stage/
>> >
>> > > > > > > >> > Problem is, the menu works just fine on the stage site,
>> but
>> > > not on
>> > > > > the
>> > > > > > > >> main
>> > > > > > > >> > site.
>> > > > > > > >> > Which is odd, as these sites should be identical.  I just
>> > > renamed
>> > > > > > > >> stage.war
>> > > > > > > >> > to main.war and let tomcat auto-deploy it
>> >
>> > > > > > > >> > The site is using tomcat 6 via apache 2 (with mod_jk
>> proxying)
>> > > > > > > >> > The problem also appears if I access tomcat directly
>> (i.e. not
>> > > via
>> > > > > > > >> apache)
>> >
>> > > > > > > >> > Is this a known issue?
>>
>>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to