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