Scott, That is a VERY true limitation of the method I proposed. I realised that after deciding to use that method in one of my projects. Whereas, it is a great idea to pull the init paramaters out with a servlet and initialise the bean there, it becomes a hassle if there are several possible creation points for the bean. *unless maybe if you created a container bean for the origional one. Use the Container bean to initialize your origional bean with init parameters from the servlet context. That way you can code your bean to be re-usable, and just use the container bean in the Servlet container. Matt Scott Stirling wrote: > This will work. But there is a limitation with it from an OO perspective. > I guess it depends how you do it, but if you're passing the bean objects > from the servlet container, and then using servlet API method calls on those > objects in the bean, you've made your bean useless outside of a servlet > container context, i.e., non-reusable. > > Does it really matter if it gets the job done and you're never going to use > the bean for anything else? No. But you could just as easily do what I > suggested in an earlier email, which is get the ServletConfig object in a > JSP or servlet, call its methods to retrieve parameters, and then use the > returned strings to set the bean's properties. That way the bean is at > least _potentially_ reusable in a servlet application context, or otherwise > (EJB, applet, etc.). > > Scott Stirling > Allaire Corporation > http://www.allaire.com/developer/jrunreferencedesk/ >
begin:vcard n:Goss;Matt tel;fax:919-657-1501 tel;work:919-657-1432 x-mozilla-html:FALSE url:www.rtci.com org:RTCI;Custom Solutions adr:;;201 Shannon Oaks Circle;Cary;NC;27511;US version:2.1 email;internet:[EMAIL PROTECTED] title:Web Developer fn:Matt end:vcard
