Ashok Kurakula

Greenhorn
+ Follow
since May 16, 2011
Merit badge: grant badges
For More
India
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Ashok Kurakula

Hi Guys,

Its too long but I request you to go through this and help me..

I work in a maintenance proect and recently we got this problem...
We have 10 different applications deployed to a single weblogic server(10.x) and we need logs of each application to be directed to different files. So we used to have log4j.properties file defined and bundled along with each ear file. It worked for several years. But now all of a sudden, server is unable to load log4j.properties files of all applications (Surprisingly it is happening only in Integration environment. In other environments, UAT and PROD, the same ear files are working fine. I dont know what's causing this, however weblogic versions in integration and other environments differ by a minor release... I mean all are 10.x bu they differ in sub-versions. I dont remember the exact version numbers.) Every time we deploy it takes only one file... we actually started the server in log4j debug mode and found that its only loading one log4j.properties file each time... The team who is responsible for the server related issues advised that you should centralize the log4j configuration and place it in some kind of shared folder where the server can find it.

We didn't have much of a choice and started working on this... I have tried a couple of options with little or no luck...

1) I defined loggers for each application and the corresponding RollingFileAppenders in the properties file and placed it in the shared path. But the problem is I have to change the way of getting Logger instance in each and every Java file. Earlier we used to get the Logger instance by sending the callers Class instance as an argument. Now I have to change this and send the logger name as an argument. It worked, but I am not willing to go this way as it is a tedious process to change this in all 10 applications.

2) I thought of defining properties programatically at application level. I did the below in ServletContextListener of each application...

I hoped that this would work, but to my surprise, configuration done in one context listener is being overridden by the configuration done in other listener of a different application. And finally all the logs are ending up in a single file. I believe that there will be a different classloader for each context and I hoped that configuration of one context wouldn't be affected by that of the other.

I have lots of questions and need answers. Can anyone answer my queries and if there is a better way to achieve my requirement, please let me know.

Thanks,
Ashok
13 years ago
Make sure that your class has a public access and your WEB-INF/classes has a proper directory structure.

Renato Bobbio Calogero wrote:
how should I test two String variables are the same , just like the Java "equals()" method ? Is this correct ?



Yes, you can test using either "eq" or "==" operators. However, this comparison is case-sensitive as it works just like "equlas()" method in Java. If you want to test the equality by ignoring the case, there isn't any operator for this. First you will have to convert them either to uppercase or lowercase (using JSTL) and then compare. More on string manipulation functions

Roy Pozarelli wrote:I've run across the issue that the subject spec does NOT list <web-fragment> and all of its elements like it does for <web-abb> (Figures/text). Is this anywhere?


I don't think that there are figures for web-fragment in the specs. But the specs clearly indicate that a web fragment is a part or all of the web.xml, meaning that it can include almost all the same elements that the web.xml uses. I think the only differences between the two are:

  • The root element for web fragments is <web-fragment>, while for the web.xml it is <web-app>
  • The web fragment descriptor file MUST be called web-fragment.xml, while the main app's deployment descriptor is called web.xml
  • For ordering purposes, web.xml contains <absolute-ordering> element while a web-fragment.xml contains an <ordering> element. Accordingly the sub elements also change.

  • Thanks for all the time you have spent on the explanation . it helped !


    Happy to hear it

    I do have a question , regarding "customer"
    So Customer is an instance of a Person.


    Yes, customer is an instance of a Person.

    ${sessionScope.customer.address}

    Which address is being mentioned here , is the Java Bean Address -OR- Person property address?
    And if it's the Person property address , how is it accessing "city" which is a property of the Java Bean Address?


    In fact, it is both. Address is a property of the Person bean and it is a JavaBean by itself. There is nothing wrong in that. Beans can have properties which are beans.
    After all, a JavaBean is nothing but a POJO(Plain Old Java Object) with some stricter naming conventions. Consider the below example.

    If you run the above code, you will get the output as "This is a String object inside TestB which is inside TestA".
    TestA has TestB and TestB has a String, right? And you are accessing TestB's String using the object of TestA.

    In the same way, you can access the "city" property(String) of "Address" bean(Object) which is inturn a property of the "Person" bean(another Object). Because as I said earlier, a JavaBean is like any other Object.

    and how we arrived the answer?
    A. ${sessionScope.customer.address.city = param.city}

    B. <c:set target="${sessionScope.customer.address)" property="city" value="${param.city"} />

    C. <c:set scope=session var="${customer.address}" property="city" value="${param.city"} />

    D.<c:set target="${sessionScope.customer.address}" property="city"> ${param.city"} </c:set>



    I think, now with the above explanation you can say, pretty confidently, that B and D are correct options. D is just another way of B, wherein the value is specified inside the body.

    A is incorrect because Expression Language (just like java expressions <%= %>) is used for getting things and writing them directly to the page. You don't do assignments in EL. So, whenever you see an assignment operator inside EL, you can say that it is wrong without any hesitation.

    C is incorrect. There are three things wrong about this.
    1) We don't use "var" attribute when we want to set properties of a bean. "var" is used for setting attributes in one of the four scopes(page, request, session and application)
    2) For "var" attribute, you just supply the name of the attribute you want to access(i.e. a String literal or an expression that results in a String), NOT the actual object
    3) "property" attribute is only used in combination with the "target" attribute. Using it in the "var" version is just an incorrect combination.

    I am getting confused with the terms Property and Attribute of JavaBean.



    Just burn this in: beans have properties while tags have attributes

    <c:set target="${sessionScope.customer.address)" property="city" value="${param.city"} />

    In the above statement, “property” (the one in blue color) is an attribute of ‘set’ tag and “city” (one in red color) is a property of address bean.

    What does the above tag do? It sets the city property of the address bean.

    But in order to achieve this, you need to supply (at least) three things to the tag.
    1. The bean (whose property you want to change)
    2. The property of the bean that you are going to change
    3. New value for that property

    And the tag holds these values with the help of its attributes.

    The “target” attribute: to hold the bean which you are targeting.
    The “property” attribute: to hold the property of a bean which you are going to set.
    The “value” attribute: to hold the value for the property.

    The naming convention is such that the attribute’s name tells you what the attribute is for.


    So a Java Bean Person has a property address would mean it has a getAddress() and setAddress() methods.



    Yes, of course. The Person class may look like this


    And the Address class may look like this


    The above is equivalent to have this below code in a scriptelet (<% ... %>)

    In fact, all this is taken care by the tag's supporting class. what we just need to do is to supply the tag with the necessary things. The chapter on Custom Tag Development will help you in getting a better idea on tag's supporting class and how the tag sends its attributes to its supporting class. I don't want to add more to your confusion. So I'll leave this here.

    What calls this method ?
    What passes a reference of type ServletContextEvent to the above method and why ?



    Container calls this method when your web app is deployed, provided that the listener is configured properly in the DD or via annotations. And it sends the ServletContextEvent object as an argument to this method for two reasons

    1. To indicate that the event of context iniatilization has occured so that you can run some code before the rest of the app starts servicing a client.

    2. To provide access to the ServletContext object via the getServletContext() method. Now you got your ServletContext object and you can do a lot of things with that. you can get context init params. you can obtain a Database connection and store it as an attribute in the context scope, so that the rest of the app can use it.

    The right element is http-method-omission. You can find it in the FIGURE 14-12 security-constraint Element Structure in the spec. I think this newblog(Dec 24, 2009) might help you.

    I think that they initially wanted to name this element as http-method-exception, but they finally setteled with the name http-method-omission. A relativiley oldblog(Dec 16, 2008) defines this element by the name http-method-exception.
    Hi Nabila,

    So since browsers maintain session , new window of the same browser will also share the same session . However , a different browser altogether will create a new session... Right?



    Yes, a different browser will always create a new session.

    Could you explain (preferably with examples) how Request Attribute and Local variables are Thread Safe ?



    Whenever there is a new request from a client, the container creates new request and response objects and sends them to the servlet's service method. After the job is done, it destroys the request and response objects. So, it always the new request object that the servlet's service method gets. Hence at any given time, a request object is never shared by multiple threads of the same servlet or of the different servlets. Hence the request attributes are thread safe.

    Local variables are always declared within the method and their scope ends with the method. So each thread has its own copy of the local variables. They can't possibly be accessed/modified by other threads. So local variables too are thread safe.
    Hi Manjula,

    I really didn't understand, how it solved your problem???

    metadata-complete="true" means that the deployment tool only examines the web.xml file and ignores annotations (such as @WebServlet, @WebFilter, and @WebListener present in the class files of the application) and any web-fragment.xml files.

    If you remove that attribute from the web-app tag, it will implicitly be set to "false", meaning that the deployment tool will scan all the files for annotations and web-fragment.xml files.

    I really don't find any connection bewteen your problem and metadata-complete attribute. Please throw some light on it...

    Thanks and Regards,
    Ashok
    Hi Manjula,

    If no <auth-constraint> element is present, then unauthenticated access will be allowed to the urls specifed in that <security-constraint> element.

    And if <auth-constraint> element is present, then only authentication will be prompted and access will be given to the roles specified within the <auth_constraint> element.

    So "no <auth_constraint>" element and "<auth-constraint><role-name>*</role-name></auth_constraint>" aren't quite same.

    I agree that the statement in HFSJ is quite misleading.