Marcos R Oliveira

Ranch Hand
+ Follow
since Apr 20, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
1
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
7
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Marcos R Oliveira

Himai Minh wrote:Hi, Marco, I see the "view Serlvet". I right click the jsp in NetBean instead of on the browser. Now, I see the generated servlet code.
Thanks.



I forgot to tell you that the click was on NetBeans window. Sorry.
Hi,

I think there is a context menu entry "view servlet" on an jsp file. Have you tried to click on it with mouse's right button?
Hi, Himai, what web container are you using?
Hi, Himai,

Looking at the generated java code for the <jsp:useBean .../> from line 2 of the JSP:


is possible to see that myAccount is always declared, having or not an instance of Account in the session scope. And that's also why having two or more <jsp:useBean .../> with same id generates translation time error.

But according to Head First or EPractice Lab, <jsp:useBean .../> first looks for a bean called myAccount.
If myAccount variable does not exist, <jsp:useBean> will create a bean and store it in a variable called myAccount.


Ok, but according to generated code above, if myAccount variable does not exist, <jsp:useBean> will create an instance of the bean and store it in a variable called myAccount that it will always declare.

About:

If myAccount exists in line 1, jsp:useBean in line 2 should be able to find it and store it in myAccount variable, instead of creating a new variable.


I think the more accurate would be:

If myAccount exists in line 1, jsp:useBean in line 2 should be able to find it and store it in myAccount variable, instead of creating a new instance.



Regards,
Marcos.
Hi, Himai,

In the second snipet:


translates to:

And then you have duplicated variable acct.
Hi,

I see... but I think that for programmatically added filters the same rule applies:

1. The order for listeners, servlets, filters if relevant must be specified in either the
web-fragment.xml or the web.xml. ...



And you can even use <absolute-ordering> element in the web.xml and <ordering> element within the web-fragment.xml

Other than that, order for filter calling is unspecified.
Thanks again! You've made excellent points! I specially liked:

"Although you could consolidate the 2 filter mappings into one, I don't think you have to, and it might even be preferable not to if you're interested in selecting the order in which filters are invoked."

and

"... Actually, it would be pretty difficult, since one of the points behind annotations is to make classes self-contained and the very concept of chaining demands knowledge outside the class."

Best regards,
Marcos.
Hi, Himai,

The two books are saying the same thing.

In Head First, the two configurations have the same effect but the user must always be authenticated because the <security-constraint> is never removed.

In the Lyon's book, the unauthenticated users have access to the application only if ALL security elements are removed: <security-constraint> and <auth-constraint>

Best regards,
Marcos.
Himai,

Chapter 8 (8.2.3) states that

... As described above, when using
annotations to define the listeners, servlets and filters, the order in which they are
invoked is unspecified. ...



and also

1. The order for listeners, servlets, filters if relevant must be specified in either the
web-fragment.xml or the web.xml. ...



Best regards,
Marcos.

Tim Holloway wrote:The web.xml file is necessary when:

1. Annotations have not been provided for one or more resources that must be defined in a web.xml context to be usable.

AND/OR

2. You wish to override an annotation value for one or more resources that must be defined in a web.xml context to be usable.

Functionally "web.xml" always exists, it's just that in olden days, you had to define it all manually and explicitly. Now it's possible for a "virtual" web.xml to be produced. This virtual web.xml is constructed by scanning the classes for web.xml-context annotations and building up equivalents. Then, if a physical web.xml exists, any entries not supplied from the annotation scan will be added and any entries that overlap annotations will override the annotation values. This is in accordance with the general practice regarding annotation specifications - class annotations are used unless overridden by an explicit outside source (usually an XML file). That reduces or eliminates the need for separate out-of-line definitions, since the XML file needs only to contain exceptions to the defaults (and any missing entries).

Incidentally, every J(2)EE web application has 2 "deployment descriptors" which define how the webapp is to be deployed and wired into the server (URL routing, resource definitions, etc.) There's a server-dependent deployment descriptor which defines server-specific characteristics. For example, a Tomcat webapp's server-dependent is its Context xml definition (which can be supplied externally, as part of a WAR, or automatically constructed from defaults). Other servers have other server-dependent deployment descriptor files and formats.

For characteristics that are not specific to a particular brand of server, there's the server-independent deployment descriptor. Which is the WEB-INF/web.xml file or an automatically constructed equivalent.



Hi, Tim! Thank you so much for your explanation!
The minute I read your POST I went right to code to make some tests and I've noticed that when comes to the filter dispatcher configuration, if it is present in both XML and annotation their values are cumulative, e.g., if we have a web.xml



and an annotaded filter as



then we have a filter that is triggered for both dispatchers: FORWARD and INCLUDE

Do you know if this behavior is mentioned somewhere in the specification? I couldn't find it.

I'm using a maven jetty plugin 9.2.15 and servlet api 3.0.1 for my tests.

Best regards,
Marcos.

Himai Minh wrote:On p.510 of Head First,


...you can't do scripting inside the body of the tag used to invoke the tag file.


I think we can do scripting inside classic tag, not simple tag.



Hi, Himai,

The book is referring to Tag Files, which are another kind of tags.

Marcos.
Hi, raghu,

Could you please, post the code of your Filter class?

Marcos.
11 years ago
Hello, Ashit,

You need to configure your filters in your application´s web.xml, as you said.

And here you can find how to do it: The Essentials of Filters

Regards,
Marcos.
Oh, I´m sorry, Lim.
I completely missed that line.

Ok, my answer remains the same: you don´t need to create a mock, you can implement it yourself, if you want:


Then you can have several getDepositManager(), one for each scenario you need to test.
13 years ago
Hi, Adolfo,

Thank you for sharing your code.

I´ll take a better look at it in a moment, but what I can tell you right now is that I wouldn´t mock the List class. I would just make query.getResultList() return null in the first expectation, new ArrayList<InviteStatus>() in the second and
Arrays.asList(new InviteStatusImpl()) in the third (assuming InviteStatus is an interface), because there are at least three scenarios in the private method to test.

Regards.
13 years ago