Re: application-level properties not component properties.

2009-06-19 Thread satar
        .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.-tp24105676p24106063.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



Re: application-level properties not component properties.

2009-06-19 Thread satar
, 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



application-level properties not component properties.

2009-06-18 Thread Steve Tarlton
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


Re: application-level properties not component properties.

2009-06-18 Thread Igor Vaynberg
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=mypropertiesproperty 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 Tarltonstarl...@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