Hi all,
I use eclipse with WTP (tomcat) but probably this method should be
applicable also to other IDE.
I edit the context.xml file in tomcat server configuration as follow
<Context>
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat
restarts -->
<!-- <Manager pathname="" /> -->
<!-- Uncomment this to enable Comet connection tacking (provides
events
on session expiration as well as webapp lifecycle) -->
<!-- <Valve
className="org.apache.catalina.valves.CometConnectionManagerValve"
/> -->
<Parameter name="dspace-config" value="e:/dspace3/config/dspace.cfg"
override="false" />
<Parameter name="dspace.dir" value="e:/dspace3" override="false" />
<Parameter name="LocalHostRestrictionFilter.localhost" value="false"
override="false" />
<Environment name="solr/home" value="e:/dspace3/solr"
type="java.lang.String"
override="false" />
</Context>
this allow me to run without change or need to filter the web.xml the
JSPUI, XMLUI and SOLR.
Please note that there are a bug with apache tomcat 6.0.30-32 that
prevent this to work:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50700
Hope this help,
Andrea
Il 18/10/2012 17:33, Robin Taylor ha scritto:
> Very very quickly thrown together so just for discussion, you could do
> something like...
>
> In dspace/pom.xml
>
> <profiles>
> <profile>
> <id>filterwebxml</id>
> <activation>
> <property>
> <name>filterwebxml</name>
> </property>
> </activation>
> <properties>
> <filter.boolean>true</filter.boolean>
> </properties>
> </profile>
> </profiles>
>
> and in dspace-jspui/pom.xml
>
> <filtering>${filter.boolean}</filtering>
>
> And then activate the profile with 'mvn package -Dfilterwebxml'
>
>
>
> On 18/10/12 15:12, TAYLOR Robin wrote:
>> Hi Tim,
>>
>> I agree, its not ideal to require developers to edit the poms for this
>> purpose. Off the top of my head, could the <resource> element in the UI
>> pom be activated by a profile ? <filtering> would be set to true by
>> default but the developer would need to run 'mvn package -P
>> filterwebxml' , or something similar. I'll try it out if I get time.
>>
>> Cheers.
>>
>>
>> On 18/10/12 14:45, Tim Donohue wrote:
>>> Hi Robin,
>>>
>>> On 10/18/2012 5:00 AM, Robin Taylor wrote:
>>>> Hi Tim,
>>>>
>>>> I don't think it was a mistake. I think part of the original motivation
>>>> was to simplify the whole business of filtering but it may have been
>>>> simplified at the expense of some useful features. In the short term you
>>>> can cause any web.xml file to be filtered by setting
>>>> <filtering>true</filtering> in the appropriate UI pom, would that
>>>> suffice ? Its set to false by default to allow filtering during the Ant
>>>> phase.
>>> Thanks for the response & suggestion. That could be a possible
>>> workaround. Though, admittedly, I think that's less "developer/IDE
>>> friendly" than before.
>>>
>>> Personally, I'm not a fan of requiring developers to tweak the POM
>>> source code before they can successfully enable webapp debugging in
>>> their IDE. I think that's my main point of frustration here -- it used
>>> to be a simple maven flag you set in your IDE
>>> (-Ddspace.config=[path-to-dspace.cfg]) that let you run a webapp from
>>> your IDE, and now you actually have to dig into Maven POM(s) and edit them.
>>>
>>> If there was a way to support webapp debugging out-of-the-box again
>>> alongside the new build.properties, I think that'd be ideal. I'm gonna
>>> dig around a bit more myself to see if I can get it working & let
>>> everyone know what I come up with.
>>>
>>> If anyone else comes up with other alternatives, let me know.
>>> Essentially, as far as I can tell, running a DSpace webapp from *any*
>>> IDE is not going to work properly unless you edit the POMs. The reason
>>> is that variables in the web.xml files are no longer filtered via Maven
>>> -- instead they get filtered later on via Ant, as Robin mentions.
>>>
>>>> In the long term I think the problem is that we use dspace.cfg to filter
>>>> dspace.dir in web.xml, but dspace.cfg already lives in dspace.dir, its
>>>> all a bit contrary. My feeling is that dspace.dir should be set outwith
>>>> the webapp, by an environment variable or some such, so that the same
>>>> webapp can be used in multiple environments without having to be rebuilt
>>>> or refiltered.
>>> I agree with you on this. The underlying problem is just that we have a
>>> messy way of doing things. I agree too that maybe dspace.dir really
>>> should be a system environment variable (DSPACE_HOME) or something like
>>> that. Something to think about for 4.0 next year.
>>>
>>> - Tim
>
--
Dott. Andrea Bollini
[email protected]
ph. +39 06 59292853 - mob. +39 348 8277525 - fax +39 06 5913770
CILEA - Consorzio Interuniversitario
http://www.cilea.it/disclaimer
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
