Kalyan avvaru

Greenhorn
+ Follow
since Mar 11, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Kalyan avvaru

Thanks for that Josh.

Any more information on how to be part of this opensource project, where I can contribute code?. This is really exciting as I might also get to learn agile and CI way to do things.


13 years ago

Well thats the stuff I am talking about!!!....Thanks Josh
13 years ago
Just trying to be creative for my project. Any other use cases people use AOP to provide services other than transaction,logging,security?.

13 years ago
Hi
I am really Springing in to action. I just finished reading through spring literatures and as with any technology best can be learnt only after seeing best implementation using technology.
Any suggestion of opensource projects that were implemented using spring. Just trying to gain practical implementation strategies and best practices in using spring and other spring related hybrid technologies.

Any one volunteer to guide and code review my implementations?
13 years ago
Thanks for that Jimmy. Thats valuable.
Just to confirm do you mean Singleton or Simpleton(which I am not aware of).

Jimmy Clark wrote:
The Simpleton design pattern is problematic, anti-object-oriented



Can you provide some conceptual reasoning for it.
Can you please provide a backing example?. I have read a lot of example out there but nothing really a strong reason to avoid them as a whole. I just understand them as a unique cases where singleton is not the right choice...or at least the way they are implemented. They made singleton as a choice and when having problems I felt cant blame singleton pattern. That said I am only getting in to junior architechting roles, so before I ridicule the use of singletons,just want to convince myself with every reason to abandon them.
Well I started this thread exactly after reading google's article. This is completely absurd. They said singleton's are hard to test due to in-extractibly coupled.
Then they even proposed a solution to to pass in the singleton as a parameter in the user's constructor, allowing a tester to easily mock out the singleton for test.
I didnt get why then is Singleton a problem...where there is indeed a solution to the proposed problem?.And I also think its practically impossible to test a class on its own in all scenarious. Classes do interact to perform a logic, in which case at some point, we will hit the wall that we need to test classes with instance of another class composed.

I think the argument is purely a personal preference rather than a best practice principle.

PS: See the comments below the article.
I had been rambling through some literature on java design patterns and what people think about them and how they put it to their practical use.
Some developers argue that Singleton patterns are bad. Every single explanation I saw, the argument is shown as they really wrote a bad use case out of the pattern.
For eg having a singleton object as a global state. Well here I dont see a problem in having a global state, but the problem is using this global state to hold objects that secretly holds objects over a algorithm/flow sequence using an API. Well here the blame goes really with the API not the pattern.

There is argument saying it is considered a good code, only if its impossible to write a bad code around it. I dont think that is really practically achievable. Its almost impossible to achieve it....only we can do our best to minimize bad code around our code. Just because its possible to write bad code in Java....we dont blame Java language as a whole.

Any thoughts/ideas/arugments............................?
Sorry ...
Can you please elucidate how to visualize threading workhorse, for a better understanding.
What are the basic principles that need to be followed for writing thread safe applications.
Chris....I have one word for you...."WOW"
I know threading is the most complicated concept. But thinking in threads in attempt to hack your way around..., seems one needs be an direct descendant of some almighty.

May be "ignorance is the bliss" applies here.
thanks for sharing Bear Bibeault.
Could you please expand on what scenarios had let to move you apps to another server?.
Really no one with comments? Atleast to slap me and discipline me to behave?
Or have I really pulled a nerve?
Hi Chris
Thanks for that input. The data visibility and synchronization is really an eye opener to me. But still its not clear to me why it matters for read only objects.
None of the user threads are changing datasource state directly. I see datasource object as a utility entity, and its state management will be abstracted to its users. There is no change in a state by any of its user threads..(directly atleast). May be to deal with visibility issue, which in this case as an utility library it should be dealt by datasource object itself, by having its state modified(if any thing it had to...which is again irrelevant for user threads) in a synchronized way way. But for a user thread(s), datasource object is still a read-only object.

I have a strong feeling...my conceptual understanding of threads is fundamentally flawed. Please enlighten me.

Regards

Jim Hoglund wrote: But remember that
objects are synchronized, not methods.



Can you please explain more on the above quote?
Do you mean its the object that has lock, which is required to be acquired by any code that has been declared to be a synchronized block?
To my knowledge you cant attribute object's declaration with 'synchronized' keyword..only code blocks/methods.

But i think it seemed more like common sense to have an inversion of control where the object itself force the code to acquire a lock, there by
what ever code trying to access the object need to acquire lock on that object.
It doesnt seem an impossible idea...and may find good use cases for it.

Am I overlooking any issue here....why java hasnt included this feature???
Does any body have any opinion about javaEE's key feature of container portability. As so far I haven't seen even a single project where there is an instance of switching a JavaEE app/web server to other servers for any reason. People do tend to stick to the choice of app server thats made at the beginning of the project for the life. Can anybody share their experience if they had to port an existing java app to a different app server. Please also share the portability issues...was it straight forward as java declares?.
Hi
Can anybody please explain....does synchronization of of any code really matters when that code is only accessing heap object in a read only way.
For eg: a datasource instance object in a servlet. Why as a principle is a good practice not to declare a instance level objects in a servlet. As I see its only a issue if the code is doing some changes to that instance level object. Here in this case a datasource object will be used only to get a new connection. Isn't it
a over generifying the principle ?