[wsas-java-dev] Websphere, WSAS and Servlet, Filter Loading

[Upul Godage]

Hi,

Just an update.

I updated the phases from the working standalone server in the local machine
for now.  MainServlet initializes without any errors. WSAS starts fine, seen
from the logs.

Login page loads fine. But login fails with "XmlHttpRequest permission
denied". There is a missing 'global_params.js' in
/wsas/modules/www/extensions/core/js.html. I could not find the file
anywhere.  When JavaScript was debugged, the URL used by Ajax calls have a
lot of 'undefined' parts.  May be because of params file.


Also on a side note, docs link in the login page looks for docs/* in the war
file.  But there was no docs directory in the war that was generated for me.

Upul




On 8/18/07, Upul Godage <upulg.dev at gmail.com> wrote:
>
> Hi Azeez,
>
> I went for a fresh installation. I got missing Addressing phase errors.
> It seems /wsas/modules/core/lib/axis2.xml used by installer thing is not
> updated with Addressing phase. I could be mistaken.
>
> Upul
>
>
> On 8/17/07, Afkham Azeez <azeez at wso2.com> wrote:
> >
> > Hi Upul,
> > I have fixed this. Now no irrelevant attributes are maintained in the
> > servlet filter. Can you test WSAS on WebSphere using the latest code
> > from the trunk?
> >
> > Thanks
> > Azeez
> >
> >
> > Upul Godage wrote:
> > > Hi all,
> > >
> > > WebSphere 6.1 in Windows XP
> > >
> > > While installing WSAS in WebSphere I found this problem. It seems WSAS
> > > depends on the state and of loading of Servlets and Filters and having
> >
> > > them as single instances unreasonably. It seems it assumes Filters
> > will
> > > be loaded first. And it tries to keep tabs on the Servlet instances
> > that
> > > is loaded by registering them with their init() method in the servlet
> > > context.
> > >
> > >
> > > org.wso2.wsas.MainServlet (with load-on-startup = 0) calls
> > > initAdminUIServletFilter which initializes a AdminUIServletFilter
> > object
> > > usingorg.wso2.adminui.init(Map ....). MainServlet assumes that
> > > AdminUIServletFilter has already initialized and registered with the
> > > servletContext. I think that is not a good assumption.
> > >
> > >
> > > In WebSphere it seems Filters are not initialized until they are
> > needed.
> > > In other used servers it looks like Filters are initialized at the
> > > startup. I think spec does not say anything about Filter loading time.
> > > So it is not predictable. WebSphere init() them when they are needed
> > for the
> > > first time. Only Servlets can be manipulated with load-on-startup or
> > > something.
> > >
> > >
> > > Also AdminUIServletFilter.init() (Standard method for initialzing
> > > Filters) is called again and again using
> > > UIInitializerServlet.initFilters().
> > >
> > >
> > > WSAS tries to keep a reference of AdminUIServletFilter in the
> > > servletContext and assumes its instance variables are initialized at
> > > startup. Although spec says there will be only once Servlet instance
> > per
> > > "JVM", it is not wise to assume there will be only one instance and
> > it's
> > > instance variables will be initialized as given.
> > >
> > >
> > > Check out these fragments.
> > >
> > >
> > >
> > > org.wso2.wsas.MainServlet
> > >
> > >
> > > (AdminUIServletFilter has not initialized yet in WebSphere at
> > > MainServlet startup.)
> > >
> > >
> > > privatevoidinitAdminUIServletFilter(ServletConfig servletConfig)
> > > throwsServletException {
> > >
> > > ConfigurationContext configCtx =serverManager.configContext;
> > >
> > > ServletContext servletContext = servletConfig.getServletContext();
> > >
> > > AdminUIServletFilter adminUIServletFilter =
> > >
> > > (AdminUIServletFilter) servletContext.
> > >
> > > getAttribute(AdminUIServletFilter.class.getName());
> > >
> > > if(adminUIServletFilter != null) {
> > >
> > > adminUIServletFilter.
> > >
> > > init((Map) configCtx.getProperty(ServerConstants.GENERATED_PAGES),
> > >
> > > Utils.isAdminConsoleEnabled(),
> > >
> > > ServerManager.httpsPort,
> > >
> > > ServerManager.httpPort,
> > >
> > > configCtx.getServicePath ());
> > >
> > > }
> > >
> > >
> > > }
> > >
> > >
> > >
> > >
> > > privatevoidreinitializeServlets(ServletContext servletContext)
> > > throwsServletException {
> > >
> > > // Reinitialize all of the servlets, for this puprpose,
> > >
> > > // the servlets should have added themselves
> > >
> > > // as ServletContext attributes in the previous init call
> > >
> > > Enumeration attributeNames = servletContext.getAttributeNames();
> > >
> > > while(attributeNames.hasMoreElements()) {
> > >
> > > Object attrib = servletContext.getAttribute((String)
> > > attributeNames.nextElement());
> > >
> > > if(attrib instanceofHttpServlet) {
> > >
> > > ((HttpServlet) attrib).init();
> > >
> > > } elseif(attrib instanceofAdminUIServletFilter) {
> > >
> > > AdminUIServletFilter adminUIServletFilter = (AdminUIServletFilter)
> > > attrib;
> > >
> > > Map genPages = (Map)serverManager.configContext.
> > >
> > > getProperty(ServerConstants.GENERATED_PAGES);
> > >
> > > adminUIServletFilter.init(genPages, Utils.isAdminConsoleEnabled(),
> > >
> > > ServerManager.httpsPort, ServerManager.httpPort,
> > >
> > > serverManager.configContext.getServicePath());
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > >
> > > When run in WebSphere uninitialized AdminUIServletFilter.doFilter()
> > > quits at,
> > >
> > >
> > > if(!enableConsole) {
> > >
> > > ServletOutputStream out = response.getOutputStream();
> > >
> > > out.write(("<b>Management Console has been disabled.</b> "+
> > >
> > > "Enable it in the server.xml and try again.").getBytes());
> > >
> > > ((HttpServletResponse)
> > > response).setStatus(HttpServletResponse.SC_FORBIDDEN);
> > >
> > > out.flush();
> > >
> > > out.close();
> > >
> > > return;
> > >
> > > }
> > >
> > >
> > > because enableConsole is always false in "fresh" AdminUIServletFilter
> > > object and it looks like it is a security problem from outside. I
> > didn't
> > > get the given message anyway.  It gave the wrong impression that
> > > something is wrong with the security settings of the unknown
> > WebSpehere
> > > territory.
> > >
> > > --
> > > Upul
> > >
> > >
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Wsas-java-dev mailing list
> > > Wsas-java-dev at wso2.org
> > > http://wso2.org/cgi-bin/mailman/listinfo/wsas-java-dev
> > b
> >
> > _______________________________________________
> > Wsas-java-dev mailing list
> > Wsas-java-dev at wso2.org
> > http://wso2.org/cgi-bin/mailman/listinfo/wsas-java-dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wso2.org/pipermail/wsas-java-dev/attachments/20070819/fe01542d/attachment.htm