SWEET, I was able to add it to my application bean directly:
<bean id="wicketApplication"
class="com.untd.bsmatrix.MatrixApplication">
<property name="hostURL" value="${app.host.url}"/>
</bean>
Of course, I have more properties like this but the first example worked as
expected!
Thanks again Igor!!!
satar wrote:
>
> Wow, thanks for such a blazing fast response Igor!
>
> Actually, I am already using the PropertyPlaceholderConfigurer (I think
> this is what you are talking about), and using different filter files for
> my different environments connected through profiles in my pom.xml file.
> Knew none of this stuff 2-3 months ago so I am trying to come to speed
> fast -- thank you Mystic Coders and WIA.
>
> I did of course check for the presence of my application.properties file
> within the tomcat webapp dir:
>
> C:\Program Files\Apache Software Foundation\Tomcat
> 5.5\webapps\bsmatrix-1.0-beta-1\WEB-INF\classes\application.properties
>
> I really resisted posting as I felt a bit of a failure as I usually can
> comb through these wonderful user groups and find my answer or a clue to
> what I am doing wrong. However, what really caught my interest and I
> didn't think about before is making them beans in my
> applicationContext.xml file with placeholders that my profile filtering
> can take care of just as it would have if I used a .properties file. That
> seems like a more natural way to do such a thing -- course, I didn't know
> what Spring was 6 months ago other than my favorite time of the year so
> who am I to say what is natural. Anyway, I think I will use beans as I am
> pretty certain that approach would work in both Jetty and Tomcat.
>
> Thanks again Igor, you ROCK!
> -Steve
>
>
> igor.vaynberg wrote:
>>
>> getClass().getClassLoader().getResourceAsStream() has always worked
>> fine for me. also did you check your war and make sure the properties
>> file was packaged?
>>
>> i see you are using spring? (ApplicationContext) if so you might want
>> to look at propertyconfigurer - it is easy to setup a bean:
>>
>> <id="properties" class="myproperties"><property name="port"
>> value="${my.port}"/></bean
>>
>> get spring to do replacement based on a properties file or jndi or
>> what have you, and then simple pull the bean out and access properties
>> via getters
>>
>> -igor
>>
>> On Thu, Jun 18, 2009 at 10:21 PM, Steve Tarlton<starl...@gmail.com>
>> wrote:
>>> I hope I finally figured out how to post to this... I am very knew to
>>> Wicket
>>> and web app development but very experience Java client application
>>> developer (Swing). I read Wicket-in-Action pretty much cover-to-cover
>>> and
>>> would highly recommend it to anyone wanting to learn Wicket!
>>>
>>> Anyway, getting to the point here, I see TONS of examples all over the
>>> net
>>> about how to setup a .properties file for a UI component but none really
>>> for
>>> setting some application-level properties. For example, the host path
>>> changes between different push locations for my app. Even on the same
>>> server
>>> I have a Jetty version at 8090 and a tomcat version at 8080. I need to
>>> know
>>> how to call back to my homepage with parameters that our
>>> single-signon-server returns. There are other things like some cgi's add
>>> to
>>> some of my pages with the Include class, which I believe you want at the
>>> very top level of your directory structure as opposed to burried in some
>>> package path.
>>>
>>> So, I though hey, I would just create a Properties instance and load it
>>> up
>>> with a call to the load() method typically so I thought why not try it
>>> beings I read somewhere that I can get an InputStream of a given class
>>> using
>>> the ClassLoader.getSystemResourceAsStream(). I thought I was clever
>>> because
>>> the following WORKED through Jetty:
>>>
>>> public class MatrixApplication extends WebApplication {
>>>
>>> private ApplicationContext ctx;
>>>
>>> // some global application-level properties
>>> private Properties applicationProperites;
>>>
>>> private static final String DEFAULT_HOST = "http://localhost:8090/";;
>>>
>>> /**
>>> * Constructor
>>> */
>>> public MatrixApplication() {
>>> }
>>>
>>>
>>> �...@override
>>> protected void init() {
>>> /*
>>> * This instructs Wicket to temporarily redirect an incoming request
>>> to
>>> in
>>> * internal Wicket page that will gather the extended browser info so
>>> I
>>> can pull
>>> * local timezone from client browser.
>>> */
>>> getRequestCycleSettings().setGatherExtendedBrowserInfo(true);
>>>
>>> /*
>>> * A special component instantiation listener that analyzes
>>> components
>>> that
>>> * get constructed and injects proxies for all the
>>> Spring-bean-annotated
>>> * members it finds.
>>> *
>>> * Note: This is required if using @SpringBean annotations.
>>> */
>>> addComponentInstantiationListener(new SpringComponentInjector(this));
>>>
>>> /*
>>> * Remove the wicket tags from the final output when rendering the
>>> pages
>>> */
>>> getMarkupSettings().setStripWicketTags(true);
>>>
>>> /*
>>> * Note: Saw this in the Mystic Coder's example. I think it is a way
>>> to
>>> * mount a page to a specific path, which could be kewl
>>> */
>>> // mountBookmarkablePage("/home", HomePage.class);
>>> /*
>>> * Added the following from Mystic Coder's example. Will need to
>>> analyze
>>> and
>>> * understand at some point.
>>> */
>>> // start
>>> ServletContext servletContext = super.getServletContext();
>>> ctx =
>>> WebApplicationContextUtils.getWebApplicationContext(servletContext);
>>>
>>> org.apache.wicket.util.lang.Objects
>>> .setObjectStreamFactory(new
>>> IObjectStreamFactory.DefaultObjectStreamFactory());
>>> // end
>>>
>>> // load our application properties so we can access them if needed
>>> loadProperties();
>>> }
>>>
>>> ...
>>>
>>> private void loadProperties() {
>>> /*
>>> * Load in the properties found in the application.properties file.
>>> */
>>> this.getClass().getClassLoader();
>>> System.out.println("Going for the resource");
>>> InputStream is = ClassLoader
>>> .getSystemResourceAsStream("application.properties");
>>> System.out.println("Finished the resource");
>>> if (is == null) {
>>> System.err.println("The application.properties file is missing.");
>>> } else {
>>> try {
>>> applicationProperites = new Properties();
>>> applicationProperites.load(is);
>>> } catch (IOException e1) {
>>> e1.printStackTrace();
>>> }
>>> }
>>> }
>>>
>>>
>>> So calling the loadProperties() from the startup of the app worked just
>>> as I
>>> had hoped when using Jetty BUT when I distributed it to a webapp under
>>> Tomcat, it failed to find the "application.properties" file. I am
>>> assuming
>>> because the classpath is different but not sure how that can be if my
>>> app
>>> works fine otherwise under Tomcat. Saw no problems until I introduced my
>>> external properties file as opposed to having it embedded in the code.
>>> Please help even if it means calling me an idiot and clueing me in on
>>> the
>>> right way to handle such a problem.
>>>
>>> Thanks,
>>> -Steve
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/application-level-properties-not-component-properties.-tp24105676p24106385.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
