JM
Jesse Martinez
Mon, Sep 17, 2012 5:45 PM
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost" rather than
the server name as set in local-settings.xml, which prevents the media
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of localhost
for the ims-url value. I've also checked that the media blob is saved
correctly in the service layer, and it is there and accessible. Might
there be somewhere else I'm failing to check? Does the app layer check
on the OS hosts file to do any sanity checks or to fill in any blanks?
I've also verified this behavior using the core tenant.
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost" rather than
the server name as set in local-settings.xml, which prevents the media
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of localhost
for the ims-url value. I've also checked that the media blob is saved
correctly in the service layer, and it is there and accessible. Might
there be somewhere else I'm failing to check? Does the app layer check
on the OS hosts file to do any sanity checks or to fill in any blanks?
I've also verified this behavior using the core tenant.
- Jesse
JM
Jesse Martinez
Tue, Sep 18, 2012 2:40 PM
OK, so it turns out that I need to edit the local-settings.xml file
BEFORE I build and deploy the app layer. Seems changing the
local-settings.xml file after the fact doesn't guarantee that the
changes are picked up. Should this be the expected behavior?
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
jmartinez@movingimage.us wrote:
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost" rather than
the server name as set in local-settings.xml, which prevents the media
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of localhost
for the ims-url value. I've also checked that the media blob is saved
correctly in the service layer, and it is there and accessible. Might
there be somewhere else I'm failing to check? Does the app layer check
on the OS hosts file to do any sanity checks or to fill in any blanks?
I've also verified this behavior using the core tenant.
OK, so it turns out that I need to edit the local-settings.xml file
BEFORE I build and deploy the app layer. Seems changing the
local-settings.xml file after the fact doesn't guarantee that the
changes are picked up. Should this be the expected behavior?
- Jesse
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
<jmartinez@movingimage.us> wrote:
> Hi all,
>
> I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
> media record blobs. The app layer is reporting "localhost" rather than
> the server name as set in local-settings.xml, which prevents the media
> blob from showing in the UI. Now, I've triple checked
> local-settings.xml for my tenant and there is no mention of localhost
> for the ims-url value. I've also checked that the media blob is saved
> correctly in the service layer, and it is there and accessible. Might
> there be somewhere else I'm failing to check? Does the app layer check
> on the OS hosts file to do any sanity checks or to fill in any blanks?
> I've also verified this behavior using the core tenant.
>
> - Jesse
RL
Ray Lee
Tue, Sep 18, 2012 5:13 PM
Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
Ray
On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
OK, so it turns out that I need to edit the local-settings.xml file
BEFORE I build and deploy the app layer. Seems changing the
local-settings.xml file after the fact doesn't guarantee that the
changes are picked up. Should this be the expected behavior?
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
jmartinez@movingimage.us wrote:
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost" rather than
the server name as set in local-settings.xml, which prevents the media
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of localhost
for the ims-url value. I've also checked that the media blob is saved
correctly in the service layer, and it is there and accessible. Might
there be somewhere else I'm failing to check? Does the app layer check
on the OS hosts file to do any sanity checks or to fill in any blanks?
I've also verified this behavior using the core tenant.
Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
Ray
On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
> OK, so it turns out that I need to edit the local-settings.xml file
> BEFORE I build and deploy the app layer. Seems changing the
> local-settings.xml file after the fact doesn't guarantee that the
> changes are picked up. Should this be the expected behavior?
>
> - Jesse
>
> On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
> <jmartinez@movingimage.us> wrote:
>> Hi all,
>>
>> I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
>> media record blobs. The app layer is reporting "localhost" rather than
>> the server name as set in local-settings.xml, which prevents the media
>> blob from showing in the UI. Now, I've triple checked
>> local-settings.xml for my tenant and there is no mention of localhost
>> for the ims-url value. I've also checked that the media blob is saved
>> correctly in the service layer, and it is there and accessible. Might
>> there be somewhere else I'm failing to check? Does the app layer check
>> on the OS hosts file to do any sanity checks or to fill in any blanks?
>> I've also verified this behavior using the core tenant.
>>
>> - Jesse
>
> _______________________________________________
> Work mailing list
> Work@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org
AR
Aron Roberts
Tue, Sep 18, 2012 6:23 PM
Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
Thanks, Ray!
On its face, this sounds like
Extraneous local-settings.xml is getting packaged in app layer .war file
http://issues.collectionspace.org/browse/CSPACE-3919
(from which, presumably, the local-settings.xml file would also go
into the exploded war directory in 'webapps')
a bug that was filed 16 months ago ...
Does that sound right?
Aron
P.S. I'll paste in your detailed response, Ray, into a comment on that JIRA.
The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
Ray
On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
OK, so it turns out that I need to edit the local-settings.xml file
BEFORE I build and deploy the app layer. Seems changing the
local-settings.xml file after the fact doesn't guarantee that the
changes are picked up. Should this be the expected behavior?
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
jmartinez@movingimage.us wrote:
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost" rather than
the server name as set in local-settings.xml, which prevents the media
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of localhost
for the ims-url value. I've also checked that the media blob is saved
correctly in the service layer, and it is there and accessible. Might
there be somewhere else I'm failing to check? Does the app layer check
on the OS hosts file to do any sanity checks or to fill in any blanks?
I've also verified this behavior using the core tenant.
On Tue, Sep 18, 2012 at 10:13 AM, Ray Lee <rhlee@berkeley.edu> wrote:
> Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
Thanks, Ray!
On its face, this sounds like
Extraneous local-settings.xml is getting packaged in app layer .war file
http://issues.collectionspace.org/browse/CSPACE-3919
(from which, presumably, the local-settings.xml file would also go
into the exploded war directory in 'webapps')
a bug that was filed 16 months ago ...
Does that sound right?
Aron
P.S. I'll paste in your detailed response, Ray, into a comment on that JIRA.
>
> The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
>
> It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
>
> Ray
>
>
> On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
>
>> OK, so it turns out that I need to edit the local-settings.xml file
>> BEFORE I build and deploy the app layer. Seems changing the
>> local-settings.xml file after the fact doesn't guarantee that the
>> changes are picked up. Should this be the expected behavior?
>>
>> - Jesse
>>
>> On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
>> <jmartinez@movingimage.us> wrote:
>>> Hi all,
>>>
>>> I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
>>> media record blobs. The app layer is reporting "localhost" rather than
>>> the server name as set in local-settings.xml, which prevents the media
>>> blob from showing in the UI. Now, I've triple checked
>>> local-settings.xml for my tenant and there is no mention of localhost
>>> for the ims-url value. I've also checked that the media blob is saved
>>> correctly in the service layer, and it is there and accessible. Might
>>> there be somewhere else I'm failing to check? Does the app layer check
>>> on the OS hosts file to do any sanity checks or to fill in any blanks?
>>> I've also verified this behavior using the core tenant.
>>>
>>> - Jesse
>>
>> _______________________________________________
>> Work mailing list
>> Work@lists.collectionspace.org
>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
PS
Patrick Schmitz
Tue, Sep 18, 2012 6:33 PM
IIRC, I have seen a bunch of copies of these settings files that get copied
during the build phase, so it is possible that you edited the wrong one...
-----Original Message-----
From: work-bounces@lists.collectionspace.org
[mailto:work-bounces@lists.collectionspace.org] On Behalf Of
Jesse Martinez
Sent: Tuesday, September 18, 2012 7:41 AM
To: CollectionSpace Work list; CollectionSpace Talk List
Subject: Re: [Work] app layer and localhost
OK, so it turns out that I need to edit the
local-settings.xml file BEFORE I build and deploy the app
layer. Seems changing the local-settings.xml file after the
fact doesn't guarantee that the changes are picked up. Should
this be the expected behavior?
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
jmartinez@movingimage.us wrote:
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost"
the server name as set in local-settings.xml, which
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of
for the ims-url value. I've also checked that the media
correctly in the service layer, and it is there and
there be somewhere else I'm failing to check? Does the app
on the OS hosts file to do any sanity checks or to fill in
I've also verified this behavior using the core tenant.
IIRC, I have seen a bunch of copies of these settings files that get copied
during the build phase, so it is possible that you edited the wrong one...
> -----Original Message-----
> From: work-bounces@lists.collectionspace.org
> [mailto:work-bounces@lists.collectionspace.org] On Behalf Of
> Jesse Martinez
> Sent: Tuesday, September 18, 2012 7:41 AM
> To: CollectionSpace Work list; CollectionSpace Talk List
> Subject: Re: [Work] app layer and localhost
>
> OK, so it turns out that I need to edit the
> local-settings.xml file BEFORE I build and deploy the app
> layer. Seems changing the local-settings.xml file after the
> fact doesn't guarantee that the changes are picked up. Should
> this be the expected behavior?
>
> - Jesse
>
> On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
> <jmartinez@movingimage.us> wrote:
> > Hi all,
> >
> > I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
> > media record blobs. The app layer is reporting "localhost"
> rather than
> > the server name as set in local-settings.xml, which
> prevents the media
> > blob from showing in the UI. Now, I've triple checked
> > local-settings.xml for my tenant and there is no mention of
> localhost
> > for the ims-url value. I've also checked that the media
> blob is saved
> > correctly in the service layer, and it is there and
> accessible. Might
> > there be somewhere else I'm failing to check? Does the app
> layer check
> > on the OS hosts file to do any sanity checks or to fill in
> any blanks?
> > I've also verified this behavior using the core tenant.
> >
> > - Jesse
>
> _______________________________________________
> Work mailing list
> Work@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/work_lists.c
> ollectionspace.org
>
PS
Patrick Schmitz
Tue, Sep 18, 2012 6:42 PM
Ignore my useless note in favor of this great one.
Thanks, Ray.
-----Original Message-----
From: work-bounces@lists.collectionspace.org
[mailto:work-bounces@lists.collectionspace.org] On Behalf Of Ray Lee
Sent: Tuesday, September 18, 2012 10:14 AM
To: Jesse Martinez
Cc: CollectionSpace Talk List; CollectionSpace Work list
Subject: Re: [Work] app layer and localhost
Oooh, right. It's not exactly expected, but we have run into
this. It turns out that when you do a full build of the app
layer, all the configuration files go into the webapp
(somewhere under webapps/collectionspace), as well as the lib
directory in tomcat. The files in the webapp take precedence
over the ones in lib. This means that any edits you make to
files in lib will have no effect, if a file with the same
name exists in the webapp.
The way we've been handling local-settings.xml is that in our
source tree, in the tenants/<tenant name> directory, there is
no local-settings.xml file. There is only a settings.xml
file. We configure everything there, with some default values
for ims-url and anything else that might change between
servers. Then, after doing a build on the server, we copy
lib/tenants/<tenant name>/settings.xml to local-settings.xml,
and edit that file. That way, editing the local-settings.xml
file in lib works, because there isn't one in the webapp,
because there wasn't one in the source tree.
It was a big surprise when we discovered that files edited in
lib had no effect, because we thought that it used to work. I
think there are a couple reasons it did appear to work
before. First, we were exclusively using the mini-build when
we first started. The mini-build, unlike a full build, only
deployed files to the tomcat lib directory. It didn't put
files in the webapp. That meant that any files we created for
a new tenant never existed in the webapp, so we could edit
them in lib, and the changes would take effect. Second, there
may have been a change in this behavior in the jboss to
tomcat switch. Richard discovered that there is an
environment variable you can set that causes the app layer to
prefer the configuration files in lib over the ones in the
webapp. I don't remember the exact name, but it had "JBOSS"
in it. It may be possible that there used to be instructions
to set this variable, but with the change to tomcat, we no
longer set it, because it looked like it was jboss specific.
Ray
On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
OK, so it turns out that I need to edit the local-settings.xml file
BEFORE I build and deploy the app layer. Seems changing the
local-settings.xml file after the fact doesn't guarantee that the
changes are picked up. Should this be the expected behavior?
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
jmartinez@movingimage.us wrote:
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong
media record blobs. The app layer is reporting "localhost" rather
than the server name as set in local-settings.xml, which
media blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention
for the ims-url value. I've also checked that the media
correctly in the service layer, and it is there and
there be somewhere else I'm failing to check? Does the app layer
check on the OS hosts file to do any sanity checks or to
I've also verified this behavior using the core tenant.
Ignore my useless note in favor of this great one.
Thanks, Ray.
> -----Original Message-----
> From: work-bounces@lists.collectionspace.org
> [mailto:work-bounces@lists.collectionspace.org] On Behalf Of Ray Lee
> Sent: Tuesday, September 18, 2012 10:14 AM
> To: Jesse Martinez
> Cc: CollectionSpace Talk List; CollectionSpace Work list
> Subject: Re: [Work] app layer and localhost
>
> Oooh, right. It's not exactly expected, but we have run into
> this. It turns out that when you do a full build of the app
> layer, all the configuration files go into the webapp
> (somewhere under webapps/collectionspace), as well as the lib
> directory in tomcat. The files in the webapp take precedence
> over the ones in lib. This means that any edits you make to
> files in lib will have no effect, if a file with the same
> name exists in the webapp.
>
> The way we've been handling local-settings.xml is that in our
> source tree, in the tenants/<tenant name> directory, there is
> no local-settings.xml file. There is only a settings.xml
> file. We configure everything there, with some default values
> for ims-url and anything else that might change between
> servers. Then, after doing a build on the server, we copy
> lib/tenants/<tenant name>/settings.xml to local-settings.xml,
> and edit that file. That way, editing the local-settings.xml
> file in lib works, because there isn't one in the webapp,
> because there wasn't one in the source tree.
>
> It was a big surprise when we discovered that files edited in
> lib had no effect, because we thought that it used to work. I
> think there are a couple reasons it did appear to work
> before. First, we were exclusively using the mini-build when
> we first started. The mini-build, unlike a full build, only
> deployed files to the tomcat lib directory. It didn't put
> files in the webapp. That meant that any files we created for
> a new tenant never existed in the webapp, so we could edit
> them in lib, and the changes would take effect. Second, there
> may have been a change in this behavior in the jboss to
> tomcat switch. Richard discovered that there is an
> environment variable you can set that causes the app layer to
> prefer the configuration files in lib over the ones in the
> webapp. I don't remember the exact name, but it had "JBOSS"
> in it. It may be possible that there used to be instructions
> to set this variable, but with the change to tomcat, we no
> longer set it, because it looked like it was jboss specific.
>
> Ray
>
>
> On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
>
> > OK, so it turns out that I need to edit the local-settings.xml file
> > BEFORE I build and deploy the app layer. Seems changing the
> > local-settings.xml file after the fact doesn't guarantee that the
> > changes are picked up. Should this be the expected behavior?
> >
> > - Jesse
> >
> > On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
> > <jmartinez@movingimage.us> wrote:
> >> Hi all,
> >>
> >> I'm working with a v2.6 stack and I'm getting some wrong
> URLs w.r.t.
> >> media record blobs. The app layer is reporting "localhost" rather
> >> than the server name as set in local-settings.xml, which
> prevents the
> >> media blob from showing in the UI. Now, I've triple checked
> >> local-settings.xml for my tenant and there is no mention
> of localhost
> >> for the ims-url value. I've also checked that the media
> blob is saved
> >> correctly in the service layer, and it is there and
> accessible. Might
> >> there be somewhere else I'm failing to check? Does the app layer
> >> check on the OS hosts file to do any sanity checks or to
> fill in any blanks?
> >> I've also verified this behavior using the core tenant.
> >>
> >> - Jesse
> >
> > _______________________________________________
> > Work mailing list
> > Work@lists.collectionspace.org
> >
> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectio
> > nspace.org
>
>
> _______________________________________________
> Work mailing list
> Work@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/work_lists.c
> ollectionspace.org
>
JM
Jesse Martinez
Tue, Sep 18, 2012 7:01 PM
This is an excellent analysis and recommendation, Ray.
On Tue, Sep 18, 2012 at 1:13 PM, Ray Lee rhlee@berkeley.edu wrote:
Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
Ray
On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
OK, so it turns out that I need to edit the local-settings.xml file
BEFORE I build and deploy the app layer. Seems changing the
local-settings.xml file after the fact doesn't guarantee that the
changes are picked up. Should this be the expected behavior?
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
jmartinez@movingimage.us wrote:
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost" rather than
the server name as set in local-settings.xml, which prevents the media
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of localhost
for the ims-url value. I've also checked that the media blob is saved
correctly in the service layer, and it is there and accessible. Might
there be somewhere else I'm failing to check? Does the app layer check
on the OS hosts file to do any sanity checks or to fill in any blanks?
I've also verified this behavior using the core tenant.
This is an excellent analysis and recommendation, Ray.
On Tue, Sep 18, 2012 at 1:13 PM, Ray Lee <rhlee@berkeley.edu> wrote:
> Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
>
> The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
>
> It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
>
> Ray
>
>
> On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
>
>> OK, so it turns out that I need to edit the local-settings.xml file
>> BEFORE I build and deploy the app layer. Seems changing the
>> local-settings.xml file after the fact doesn't guarantee that the
>> changes are picked up. Should this be the expected behavior?
>>
>> - Jesse
>>
>> On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
>> <jmartinez@movingimage.us> wrote:
>>> Hi all,
>>>
>>> I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
>>> media record blobs. The app layer is reporting "localhost" rather than
>>> the server name as set in local-settings.xml, which prevents the media
>>> blob from showing in the UI. Now, I've triple checked
>>> local-settings.xml for my tenant and there is no mention of localhost
>>> for the ims-url value. I've also checked that the media blob is saved
>>> correctly in the service layer, and it is there and accessible. Might
>>> there be somewhere else I'm failing to check? Does the app layer check
>>> on the OS hosts file to do any sanity checks or to fill in any blanks?
>>> I've also verified this behavior using the core tenant.
>>>
>>> - Jesse
>>
>> _______________________________________________
>> Work mailing list
>> Work@lists.collectionspace.org
>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org
>
RL
Ray Lee
Tue, Sep 18, 2012 7:13 PM
Aron,
I'm not sure if CSPACE-3919 is still a bug. There doesn't seem to be a local-settings.xml checked in, in defaults, tenants/core, or tenants/lifesci. So I believe that if you do a full build of the app layer, you'll be able to create and edit a local-settings.xml in lib/tenants/core and lib/tenants/lifesci, and it will take effect (although someone should verify this). However, the recommendation in the description definitely applies to those of us who are creating new tenants. That is, local-settings.xml should not be committed to the source tree in our tenants; it should only be manually added to local deployments. It's possible this is only a documentation issue at this point.
Ray
On Sep 18, 2012, at 11:23 AM, Aron Roberts wrote:
Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
Thanks, Ray!
On its face, this sounds like
Extraneous local-settings.xml is getting packaged in app layer .war file
http://issues.collectionspace.org/browse/CSPACE-3919
(from which, presumably, the local-settings.xml file would also go
into the exploded war directory in 'webapps')
a bug that was filed 16 months ago ...
Does that sound right?
Aron
P.S. I'll paste in your detailed response, Ray, into a comment on that JIRA.
The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
Ray
On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
OK, so it turns out that I need to edit the local-settings.xml file
BEFORE I build and deploy the app layer. Seems changing the
local-settings.xml file after the fact doesn't guarantee that the
changes are picked up. Should this be the expected behavior?
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
jmartinez@movingimage.us wrote:
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost" rather than
the server name as set in local-settings.xml, which prevents the media
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of localhost
for the ims-url value. I've also checked that the media blob is saved
correctly in the service layer, and it is there and accessible. Might
there be somewhere else I'm failing to check? Does the app layer check
on the OS hosts file to do any sanity checks or to fill in any blanks?
I've also verified this behavior using the core tenant.
Aron,
I'm not sure if CSPACE-3919 is still a bug. There doesn't seem to be a local-settings.xml checked in, in defaults, tenants/core, or tenants/lifesci. So I believe that if you do a full build of the app layer, you'll be able to create and edit a local-settings.xml in lib/tenants/core and lib/tenants/lifesci, and it will take effect (although someone should verify this). However, the recommendation in the description definitely applies to those of us who are creating new tenants. That is, local-settings.xml should not be committed to the source tree in our tenants; it should only be manually added to local deployments. It's possible this is only a documentation issue at this point.
Ray
On Sep 18, 2012, at 11:23 AM, Aron Roberts wrote:
> On Tue, Sep 18, 2012 at 10:13 AM, Ray Lee <rhlee@berkeley.edu> wrote:
>> Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
>
> Thanks, Ray!
>
> On its face, this sounds like
>
> Extraneous local-settings.xml is getting packaged in app layer .war file
> http://issues.collectionspace.org/browse/CSPACE-3919
> (from which, presumably, the local-settings.xml file would also go
> into the exploded war directory in 'webapps')
>
> a bug that was filed 16 months ago ...
>
> Does that sound right?
>
> Aron
>
> P.S. I'll paste in your detailed response, Ray, into a comment on that JIRA.
>
>>
>> The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
>>
>> It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
>>
>> Ray
>>
>>
>> On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
>>
>>> OK, so it turns out that I need to edit the local-settings.xml file
>>> BEFORE I build and deploy the app layer. Seems changing the
>>> local-settings.xml file after the fact doesn't guarantee that the
>>> changes are picked up. Should this be the expected behavior?
>>>
>>> - Jesse
>>>
>>> On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
>>> <jmartinez@movingimage.us> wrote:
>>>> Hi all,
>>>>
>>>> I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
>>>> media record blobs. The app layer is reporting "localhost" rather than
>>>> the server name as set in local-settings.xml, which prevents the media
>>>> blob from showing in the UI. Now, I've triple checked
>>>> local-settings.xml for my tenant and there is no mention of localhost
>>>> for the ims-url value. I've also checked that the media blob is saved
>>>> correctly in the service layer, and it is there and accessible. Might
>>>> there be somewhere else I'm failing to check? Does the app layer check
>>>> on the OS hosts file to do any sanity checks or to fill in any blanks?
>>>> I've also verified this behavior using the core tenant.
>>>>
>>>> - Jesse
>>>
>>> _______________________________________________
>>> Work mailing list
>>> Work@lists.collectionspace.org
>>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org
>>
>>
>> _______________________________________________
>> Talk mailing list
>> Talk@lists.collectionspace.org
>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
JM
Jesse Martinez
Tue, Sep 18, 2012 7:31 PM
Interesting. I do have a local-settings.xml in my mmi tenant directory
from which I build from. I must have naively added it thinking it was
the right procedure. I tend to keep that local-settings.xml instance
with default values lest I commit something with passwords added in. I
must have rebuilt the app layer at one point with the default values
by mistake then changed those values within the tomcat lib/tenants/mmi
directory post-build thinking this would work.
On Tue, Sep 18, 2012 at 3:13 PM, Ray Lee rhlee@berkeley.edu wrote:
Aron,
I'm not sure if CSPACE-3919 is still a bug. There doesn't seem to be a local-settings.xml checked in, in defaults, tenants/core, or tenants/lifesci. So I believe that if you do a full build of the app layer, you'll be able to create and edit a local-settings.xml in lib/tenants/core and lib/tenants/lifesci, and it will take effect (although someone should verify this). However, the recommendation in the description definitely applies to those of us who are creating new tenants. That is, local-settings.xml should not be committed to the source tree in our tenants; it should only be manually added to local deployments. It's possible this is only a documentation issue at this point.
Ray
On Sep 18, 2012, at 11:23 AM, Aron Roberts wrote:
Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
Thanks, Ray!
On its face, this sounds like
Extraneous local-settings.xml is getting packaged in app layer .war file
http://issues.collectionspace.org/browse/CSPACE-3919
(from which, presumably, the local-settings.xml file would also go
into the exploded war directory in 'webapps')
a bug that was filed 16 months ago ...
Does that sound right?
Aron
P.S. I'll paste in your detailed response, Ray, into a comment on that JIRA.
The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
Ray
On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
OK, so it turns out that I need to edit the local-settings.xml file
BEFORE I build and deploy the app layer. Seems changing the
local-settings.xml file after the fact doesn't guarantee that the
changes are picked up. Should this be the expected behavior?
On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
jmartinez@movingimage.us wrote:
Hi all,
I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
media record blobs. The app layer is reporting "localhost" rather than
the server name as set in local-settings.xml, which prevents the media
blob from showing in the UI. Now, I've triple checked
local-settings.xml for my tenant and there is no mention of localhost
for the ims-url value. I've also checked that the media blob is saved
correctly in the service layer, and it is there and accessible. Might
there be somewhere else I'm failing to check? Does the app layer check
on the OS hosts file to do any sanity checks or to fill in any blanks?
I've also verified this behavior using the core tenant.
Interesting. I do have a local-settings.xml in my mmi tenant directory
from which I build from. I must have naively added it thinking it was
the right procedure. I tend to keep that local-settings.xml instance
with default values lest I commit something with passwords added in. I
must have rebuilt the app layer at one point with the default values
by mistake then changed those values within the tomcat lib/tenants/mmi
directory post-build thinking this would work.
On Tue, Sep 18, 2012 at 3:13 PM, Ray Lee <rhlee@berkeley.edu> wrote:
> Aron,
> I'm not sure if CSPACE-3919 is still a bug. There doesn't seem to be a local-settings.xml checked in, in defaults, tenants/core, or tenants/lifesci. So I believe that if you do a full build of the app layer, you'll be able to create and edit a local-settings.xml in lib/tenants/core and lib/tenants/lifesci, and it will take effect (although someone should verify this). However, the recommendation in the description definitely applies to those of us who are creating new tenants. That is, local-settings.xml should not be committed to the source tree in our tenants; it should only be manually added to local deployments. It's possible this is only a documentation issue at this point.
>
> Ray
>
>
>
> On Sep 18, 2012, at 11:23 AM, Aron Roberts wrote:
>
>> On Tue, Sep 18, 2012 at 10:13 AM, Ray Lee <rhlee@berkeley.edu> wrote:
>>> Oooh, right. It's not exactly expected, but we have run into this. It turns out that when you do a full build of the app layer, all the configuration files go into the webapp (somewhere under webapps/collectionspace), as well as the lib directory in tomcat. The files in the webapp take precedence over the ones in lib. This means that any edits you make to files in lib will have no effect, if a file with the same name exists in the webapp.
>>
>> Thanks, Ray!
>>
>> On its face, this sounds like
>>
>> Extraneous local-settings.xml is getting packaged in app layer .war file
>> http://issues.collectionspace.org/browse/CSPACE-3919
>> (from which, presumably, the local-settings.xml file would also go
>> into the exploded war directory in 'webapps')
>>
>> a bug that was filed 16 months ago ...
>>
>> Does that sound right?
>>
>> Aron
>>
>> P.S. I'll paste in your detailed response, Ray, into a comment on that JIRA.
>>
>>>
>>> The way we've been handling local-settings.xml is that in our source tree, in the tenants/<tenant name> directory, there is no local-settings.xml file. There is only a settings.xml file. We configure everything there, with some default values for ims-url and anything else that might change between servers. Then, after doing a build on the server, we copy lib/tenants/<tenant name>/settings.xml to local-settings.xml, and edit that file. That way, editing the local-settings.xml file in lib works, because there isn't one in the webapp, because there wasn't one in the source tree.
>>>
>>> It was a big surprise when we discovered that files edited in lib had no effect, because we thought that it used to work. I think there are a couple reasons it did appear to work before. First, we were exclusively using the mini-build when we first started. The mini-build, unlike a full build, only deployed files to the tomcat lib directory. It didn't put files in the webapp. That meant that any files we created for a new tenant never existed in the webapp, so we could edit them in lib, and the changes would take effect. Second, there may have been a change in this behavior in the jboss to tomcat switch. Richard discovered that there is an environment variable you can set that causes the app layer to prefer the configuration files in lib over the ones in the webapp. I don't remember the exact name, but it had "JBOSS" in it. It may be possible that there used to be instructions to set this variable, but with the change to tomcat, we no longer set it, because it looked like it was jboss specific.
>>>
>>> Ray
>>>
>>>
>>> On Sep 18, 2012, at 7:40 AM, Jesse Martinez wrote:
>>>
>>>> OK, so it turns out that I need to edit the local-settings.xml file
>>>> BEFORE I build and deploy the app layer. Seems changing the
>>>> local-settings.xml file after the fact doesn't guarantee that the
>>>> changes are picked up. Should this be the expected behavior?
>>>>
>>>> - Jesse
>>>>
>>>> On Mon, Sep 17, 2012 at 1:45 PM, Jesse Martinez
>>>> <jmartinez@movingimage.us> wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm working with a v2.6 stack and I'm getting some wrong URLs w.r.t.
>>>>> media record blobs. The app layer is reporting "localhost" rather than
>>>>> the server name as set in local-settings.xml, which prevents the media
>>>>> blob from showing in the UI. Now, I've triple checked
>>>>> local-settings.xml for my tenant and there is no mention of localhost
>>>>> for the ims-url value. I've also checked that the media blob is saved
>>>>> correctly in the service layer, and it is there and accessible. Might
>>>>> there be somewhere else I'm failing to check? Does the app layer check
>>>>> on the OS hosts file to do any sanity checks or to fill in any blanks?
>>>>> I've also verified this behavior using the core tenant.
>>>>>
>>>>> - Jesse
>>>>
>>>> _______________________________________________
>>>> Work mailing list
>>>> Work@lists.collectionspace.org
>>>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org
>>>
>>>
>>> _______________________________________________
>>> Talk mailing list
>>> Talk@lists.collectionspace.org
>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
