Thibault Dangr�aux

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

Recent posts by Thibault Dangr�aux

Originally posted by geetu lalchandani:
if i use a custom tag in the jsp.. will the same pagecontext be shared between the page and the tag???



Yes. That's used by the i18n tags for instance. The fmt:setFormat tag will set the locale inside the pageContext (by default) and all the other i18n tags will read it from there.
18 years ago
JSP
Isn't it a litteral actually? With "false" representing the value "false"?
18 years ago
Sometime, you also need to get your hands dirty and do some low level stuff. And then, the best technology often remains the servlet and plain old Java.
Some examples might be :
- serving binary content, for instance images. Applications might be watermarking images, applying transformation on images or generating images on the fly.
- generating views that are highly recursive. For instance, rendering a complex navigation bar is a pain in JSP or any view technology, but very straightforward in Java (through include mechanisme) or a custom tag. The first is often easier when you need a real controller to prepare the structure before rendering it in a "Java view".
- doing some very specific stuff that falls outside a framework.

Besides, some framework do not protect you from the details of how servlet works. For instance, Spring MVC controllers are pretty close to a servlet. I don't think you can do anything serious in them if you have no idea on how a servlet works.
18 years ago
The first things to check is whether your servlets/controllers (and the services and POJO used by them) are thread-safe *and* stateless. Without looking at your code, a problem that only occurs during concurrent accesses would suggest something like this...
18 years ago
You really need an application scope cache...
You might look at EhCache too, it's the default cache for hibernate, and it does a decent job and has some niceties, like xml configuration and thread safety.
While you're at it, you might consider using hibernate as your DAO framework... Among lots of niceties, you will get transparent and configurable caching.

But in away way, caching does involve the potential for loss of synchronization. Hibernate will behave nicely, as long as *only* your application updates the data. If data is updated from some other source, you will have to deal with potentially stale data...
18 years ago
It's also a problem with some teachers, though I expect it to have diminished in the recent years... Some teachers come from a procedural programming background. So, they fail to understand the specifics of OOP and think that using OOP is all about encoding good old algorithmics into classes. I have had bunch of teachers like this. The telltale sign was when most of the code ended up in the main()...
Actually, OOP is all about code reuse, API knowledge, event oriented programming, component oriented programming, design pattern, object interaction and a *little* algorithmics.
18 years ago
That's a common pitfall for C++ programmers...
In Java, specifying "protected" rather than nothing (package) actually relaxes the security policy, since it makes the qualified item (field or method) accessible from both children and classes from the same package.
private < package < protected < public.
18 years ago
I second Bear. Implement a DAO, and eventually a service pattern.
Your controller (well, action since you're using Struts) will query that DAO (or service) and store the result list as a request attribute. Then, your JSP will render that list in whatever HTML form you pick, without worrying about where that data came from.
That way, you have proper MVC separation. If you decide to get your data from another source (hibernate rather than straight SQL, XML service, static collection for debugging...), you just have to touch your service (or DAO) layer without impacting anything else.
18 years ago
JSP
Also, most of the limits of singletons tend to disappear when you use a framework like Spring. Essentially, all beans created by Spring are singletons as per the default behaviour.
However (going through http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx) :
1) Spring takes care of the glue. If you want to know what singletons a class uses, you just have to look at the XML wiring or the setters of that class. Also, you don't have to deal directly with global variables - they're being pushed onto you by Spring.
2) Using Spring, a class does not need to know it is a singleton. All it has to do is make sure it is stateless and thread-safe.
3) You don't have to be tightly coupled if you use interfaces. Your singleton implements an interface. And all its clients talk to that interface. Then, it's very easy to plug different implementations through bean wiring.
4) That's indeed a limitation, but that's also the main feature of singletons - it's actually why they exist at all. It's a very important feature when setup is heavy. For instance, I have beans which (indirectly) query a database, read and parse half a dozen XML files and makes a few Internet connections as part of their setup. Doing that every single time I need a bean like this would be crazy. Likewise, it would be close to impossible to implement application-wide caching of anything without some form of singleton.

Actually, I think that singletons + IoC pattern can be the real backbone of an application. With it, designing service or DAO patterns is very easy. You can very easily plug in real implementations, mock implementations or alternative implementations.
18 years ago
Inheriting from java.lang.Object is not what defines OOPness : C++ does not have a common root Object, yet it is still an OOP language.
String is an object : the inability to inherit from it is a *design* decision, marked by a language keyword ("final") - if you edited the source of the String class to remove that keyword, you would be able to inherit from String.
Indeed int is easier to use than Integer. That's why the conceptors of Java made the design decision to stir away from pure OOPness to increase the language efficiency and ease of use. Just like C++ conceptors decided to trade off some pure OOPness in order to increase speed of execution and C-friendliness (static binding by default, primitives, friends...).
But there are times when you do need int to be an object. For instance, when you need it in a collection. That's why you have to wrap it in an Integer - or why you let the language do it with auto-boxing if using Java 5.

Primitives are not objects. Not because they lack inheritance or have a special syntax. But because they are primitives - otherwise, they would be called objects. They lack encapsulation (a primitive is its own value - no encapsulation at all), they lack polymorphism and of course they lack inheritance. If it crawls, barks and has four legs, it's very unlikely to be a bird.

Likewise, the special syntax for int has nothing to do with them being OOP or not; it is a design decision in Java not to have operator overloading. In C++, you can build a Matrix or Complex object and use regular + or * operators on it.

As for actor languages, they have been mainly used in research and AI. They push the OOP concept further than the class language branch (Smalltalk, Simula, C++, Java...). In an actor language, each object runs in its own execution space (thread, process...). It receives messages from other objects, processes them asynchronously and then sends an appropriate answer through another message. Of course, one actor can inherit from another. Encapsulation is very much enforced : an actor's internal is extremelly private. That's a very pure OOP concept : everything is an actor. The only mean of communication is through messages. And of course, it's slow as hell... You can push the concept very far. Actually, many statements can be turned into actors : an actor could handle looping or comparison for instance.
18 years ago
Actually, an int is NOT an object. For instance, you can't create a reference to an int, you can just copy its value around. Likewise, you can't inherit from int. Moreover, the conversion between the primitive types are not based on polymorphism an inheritance, as they should, but on static hard coded rules and strategies.
That's why Java uses wrapper classes : you *need* them to make many features work with int - because int is not an object.

As for OOP languages, the problem is that there is not a single definition of what an OOP language is. Smalltalk, which inspired Java, Simula or Eiffel (and to a lesser extent C++) is the leader of *one* family of OOP languages, the most successfull one. But there are other ones, like frame languages or actor languages, where "object" has a very different meaning. I'm sure many researchers which deal with OOP languages based on the actor paradygm would consider even Smalltalk to be very far from a pure OOP language - after all, it's very static compared to a language based on actors!
18 years ago
Besides, Java is not pure OOP, since it has primitive types (int, long...) that do not inherit from Object and are not objects themselves (hence the wrapper types).
In a pure OOP languages, like Smalltalk, everything would be objects, no primitive types...
But Java is more OOP than C++, because of stuff like introspection and reflection, which means the coding itself is built of objects.
18 years ago
Pro Spring is good.
Spring in Action is good too, but I find it harder to use as a learning book - but it covers more stuff and has more details.

But am I the only one to find that the official Spring documentation is actually pretty good? It's almost as good as the hibernate one, which is one of the very best documentations for an Open Source project...
Same here. It's a very good learning book. And, despite what its look might suggest, it's not a "dummy" book; it covers a very broad area of subject with significant depth.
But it's true that it's a little hard to use as a reference book... Though by the time you really need a pure reference book, the Javadoc and Internet are often all you need!
18 years ago
When you test that, do you have cookies enabled? If cookies are not enabled, the server will not be able to track session accross pages, unless you take special steps (URL rewriting et response.encodeUrl).
18 years ago