Tuesday, August 23, 2005
DB2 deadlock issue
I have been experiencing this issue: SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code "2". This is on a newly developed j2ee based SOA app that uses db2 jdbc driver to access the db. Quick search on google groups and google regular revealed as usual a plethora of settings that needs to be done on the db2 sie of the house. Reminded me of the plethora of settings that we had to work with websphere and WSAD. This makes me wonder, Is this one of the value points or corporate manthra of IBM's products to just make even the simplest features appear complicated and thus earn revenues thru service and support?
Saturday, August 06, 2005
Jury duty experience
Was summoned for Jury duty the week of Aug 1st. I had become a US citizen just couple of months back. This was my first experience with the US judicial system. Was asked to fill in a form and asked to affirm the oath that I would tell the truth. Was surprised by the large number of people ( anywhere between 75 to 100 ). Apparently there are a lot of civil and criminal cases going on.
I organizer forewarned for the first timers that jury duty involves a lot of wait. That tells me the system has some flaws. Luckily they had a projection TV and started screening Village movie. Eventhough I had seen the movie before I didn't mind watching over again. Couple of times the movie was paused and the organizer called out 30 names in random by the order of some judge. The movie was almost reaching a climax where the blind girl is in the forest all by herself when it was paused again. This time my name was the first to be called amongst 30 chosen. After some minor procedure explanation we were taken to the court room. The judge and the defendant and the attorney were there. The clerk called in 12 names at random to sit in the jury box. The prosecuting attorney briefly introduced the case.
It was case bought in by the DA's office of NC against a 19 year old boy. The charges were taking indecent liberties with a child and committing a act against Nature. Some of the jurors were not comfortable hearing about anal sex and specifics. Both the prosecuting attorney and defense interviewed the jury and I was called into the 12 after one of the jurors had to be excused. The jury selection went on the whole day and continued on the next day. Finally they had 12 + 1 alternate juror as backup. The incident occurred on Dec 28 2003 and only now it is being heard. Whatever happened to the concept of Justice delayed is justice denied. The first witness was the victim himself. The witnesses testified the next couple of days. At the end of all the testimonies the judge explained to us what the charges are and what is the law is and what the sentence would be if found guilty.
We were off to the jury room to deliberate. We took an initial vote and it was 8 to 4 for not guilty vs guilty. Next 5 hours the deliberation went on. No consensus. We informed the judge we cannot unanimously agree on a decision. The judge declared the trial as a mistrial and sent us back home after 4 days. That is all to it.
Both the victim and defendant being boys ( 17 and 12) no big deal the claim of rape. There were too many inconsistencies in the victims story. In fact all jurors agreed that the defendant was setup. It is just the age factor that made the incident a crime.
I organizer forewarned for the first timers that jury duty involves a lot of wait. That tells me the system has some flaws. Luckily they had a projection TV and started screening Village movie. Eventhough I had seen the movie before I didn't mind watching over again. Couple of times the movie was paused and the organizer called out 30 names in random by the order of some judge. The movie was almost reaching a climax where the blind girl is in the forest all by herself when it was paused again. This time my name was the first to be called amongst 30 chosen. After some minor procedure explanation we were taken to the court room. The judge and the defendant and the attorney were there. The clerk called in 12 names at random to sit in the jury box. The prosecuting attorney briefly introduced the case.
It was case bought in by the DA's office of NC against a 19 year old boy. The charges were taking indecent liberties with a child and committing a act against Nature. Some of the jurors were not comfortable hearing about anal sex and specifics. Both the prosecuting attorney and defense interviewed the jury and I was called into the 12 after one of the jurors had to be excused. The jury selection went on the whole day and continued on the next day. Finally they had 12 + 1 alternate juror as backup. The incident occurred on Dec 28 2003 and only now it is being heard. Whatever happened to the concept of Justice delayed is justice denied. The first witness was the victim himself. The witnesses testified the next couple of days. At the end of all the testimonies the judge explained to us what the charges are and what is the law is and what the sentence would be if found guilty.
We were off to the jury room to deliberate. We took an initial vote and it was 8 to 4 for not guilty vs guilty. Next 5 hours the deliberation went on. No consensus. We informed the judge we cannot unanimously agree on a decision. The judge declared the trial as a mistrial and sent us back home after 4 days. That is all to it.
Both the victim and defendant being boys ( 17 and 12) no big deal the claim of rape. There were too many inconsistencies in the victims story. In fact all jurors agreed that the defendant was setup. It is just the age factor that made the incident a crime.
Sunday, July 10, 2005
Worthy Sentences
Though I am not perfect, I do the best that I can do at this time in my life
I deserve to take better care of my family and me
Goals of S-M-A-R-T
S- Specific M - Measurable A- Attainable R- Relevant T- Time Based
For example, a specific short-term goal may be to start strength training; the long-term goal may be easing the symptoms of arthritis, improving balance, or controlling your weight. This goal is easily measurable: Have you or have you not begun the program? Indeed, this is an attainable goal, as long as your doctor approves, and this goal is certainly relevant to living a long, healthy life. Your goal needs to be time-based
I deserve to take better care of my family and me
Goals of S-M-A-R-T
S- Specific M - Measurable A- Attainable R- Relevant T- Time Based
For example, a specific short-term goal may be to start strength training; the long-term goal may be easing the symptoms of arthritis, improving balance, or controlling your weight. This goal is easily measurable: Have you or have you not begun the program? Indeed, this is an attainable goal, as long as your doctor approves, and this goal is certainly relevant to living a long, healthy life. Your goal needs to be time-based
Monday, July 04, 2005
Tuesday, June 07, 2005
SImple way to kill phising
The simple way to kill phishing is by making it harder for the phisher to make money from it. If you get phishing e-mail, go the web sites and enter false data. Make up everything -- name, sign-on name, password, credit card numbers, everything. Instead of one million messages yielding 100 good replies, now the phisher will have one million messages yielding 100,000 replies of which 100 are good, but WHICH 100?
This technique kills phishing two ways. It certainly increases the phishing labor requirement by about 10,000X. But even more importantly, if banks and e-commerce sites limit the number of failed sign-on attempts from a single IP address to, say, 10 per day, theft as an outcome of phishing becomes close to impossible.
This technique kills phishing two ways. It certainly increases the phishing labor requirement by about 10,000X. But even more importantly, if banks and e-commerce sites limit the number of failed sign-on attempts from a single IP address to, say, 10 per day, theft as an outcome of phishing becomes close to impossible.
Wednesday, June 01, 2005
Fundamentals of Business
From http://calacanis.weblogsinc.com/entry/1234000053039351/
Business is about three very basic things:
1. Hustle
2. Passion
3. Resiliency
You have those things it really doesn’t matter what the idea is… you can change your ideas all day long, in fact evolving is what you’re supposed to do in business. However, you can’t substitute hustle, passion, or resiliency.
You can certainly learn, and defiantly enhance, those three core attributes. People get caught up in the text book theories of business and forget reality. Serving customers, being passionate about what you do, serving more, caring more, giving more...that's what makes success. Know your customer, solve a need, and deliver value to your customer.
Business is about three very basic things:
1. Hustle
2. Passion
3. Resiliency
You have those things it really doesn’t matter what the idea is… you can change your ideas all day long, in fact evolving is what you’re supposed to do in business. However, you can’t substitute hustle, passion, or resiliency.
You can certainly learn, and defiantly enhance, those three core attributes. People get caught up in the text book theories of business and forget reality. Serving customers, being passionate about what you do, serving more, caring more, giving more...that's what makes success. Know your customer, solve a need, and deliver value to your customer.
Friday, May 27, 2005
Good developer
A good developer need to understand the business, and as as a minimum understand that you are being hired to create solutions to business problems.
Be able to look at a business, see and understand the problems the business currently faces, innovate to solve said problems, and then are able to communicate with a non-technical audience the business benefit of the technical solution. Focus more on understanding the customer than on understanding the technology ('though you need both, of course).So, things like usability are critical.
Another crucial component of any good developers repertoire is change management, a good developer has to not just cope with change, but embrace it. When you approach a problem domain you look at it without thinking about the technology. You look at it from a business perspective, find the requirements, the end-users etc and then once you have done that you then decide on the technology. Now this may be a Java solution, but then maybe it is a .NET one or PHP or VB or whatever it has to be right for the business. I would expect any developer to be able to adapt and to pick up whatever the choice may be and become productive. The forementioned reason is why I am unimpressed with those who can recite the Java API from memory, my personal feeling on this is that you should now what is available (whether it be in Java, PHP, Perl, C/C++ whatever) from a higher level and not confine yourself to a particular technical space. However, how to use it (ie the API) you don't need to know to a great level of detail until you actually start the work.
Be able to look at a business, see and understand the problems the business currently faces, innovate to solve said problems, and then are able to communicate with a non-technical audience the business benefit of the technical solution. Focus more on understanding the customer than on understanding the technology ('though you need both, of course).So, things like usability are critical.
Another crucial component of any good developers repertoire is change management, a good developer has to not just cope with change, but embrace it. When you approach a problem domain you look at it without thinking about the technology. You look at it from a business perspective, find the requirements, the end-users etc and then once you have done that you then decide on the technology. Now this may be a Java solution, but then maybe it is a .NET one or PHP or VB or whatever it has to be right for the business. I would expect any developer to be able to adapt and to pick up whatever the choice may be and become productive. The forementioned reason is why I am unimpressed with those who can recite the Java API from memory, my personal feeling on this is that you should now what is available (whether it be in Java, PHP, Perl, C/C++ whatever) from a higher level and not confine yourself to a particular technical space. However, how to use it (ie the API) you don't need to know to a great level of detail until you actually start the work.
Wednesday, April 13, 2005
Layered Architecture design
Taken from http://www.hibernate.org/124.html
Just to expand on the architecture I chose (and have briefly and disjunctly discussed on the forum). Let me first suggest a great book on this subject, written by Martin Fowler, entitled "Patterns of Enterprise Application Architecture". It is extremely insightful, helpful and well written.
It seems that most of the discussion that I have seen on the forums regarding this topic relate to whether the objects mapped in Hibernate should be returned as-is to the clients, or whether some form of abstraction should be used to represent that data (whether XML, DTO, Commands, etc). To me, each approach has pros and cons. In my architecture, I chose the latter using DTOs as the communication medium with the presentation. In brief, my architecture is as follows:
1. At the bottom tier is a very strong domain layer (mapped using Hibernate). By very strong, I mean that it bundles all the data elements mapped from Hibernate along with a lot of domain logic (see the section discussing business logic vs domain logic in the chapter on the "service layer" pattern in Fowler's book)...
2. A set of DAOs with static methods for various methods of locating domain objects using HQL or session.load()
3. A service layer, implemented as session beans for no other reason than for the transaction support as I have to coordinate transactions across JMS, LDAP as well as the DB. This could easily be non-ejb also, possibly using aspects to acheive transaction "cross-cuts".
4. a set of "assemblers" (again, see Fowler) which are responsible for "molding" domain objects into DTOs and "swizzling" DTO data back into domain objects.
5. a slew of DTOs which carry data to and from the clients of the service layer.
To me, there are a couple of pros to this type of approach. Number one would have to be the fact that it completely decouples the client from anything that happens behind the service layer, and vice versa. Part of this is not having to worry about things like whether lazy relationships have been loaded when adding a new column to a search result table. Another advantage is that is gives your app a much more defined API feel. The methods exposed on the service layer are the functionality provided by the system to the outside world. And because a lot of the "nitty-gritty" code is hidden away in the DAOs and the assemblers, the service code is very clean. An example would be:
public ContactDTO loadContact( Long contactId )
throws my.PersistenceException
{
prepareCall();
try
{
return ContactAssembler.buildDTO( ContactDAO.load( contactId ) );
}
catch( Exception e )
{
throw new my.PersistenceException( "Unable to load contact", e );
}
finally
{
endCall();
}
}
The cons mainly deal with the fact that that's a lot of extra classes to code. At a minimum, in a small app, you can assume about a one-to-one correspondence between the domain objects in your app and their various DTO representations; this may be even bigger for larger apps. Why? Mainly it has to do with relationships and avoiding infinite loops. Consider a ContactDTO with a relationship to a CompanyDTO, which in turn has a collection relation to its employees which are ContactDTOs. This is normally handled by having different DTO representations of data with different "loading levels" (similiar to the Lightweight pattern discussed on the Hibernate patterns page). Thus, you now would have something like ContactDTO -> CompanyDTO -> ContactListDTO. And thats not even considering specialty DTOs like report DTOs, etc. Its hopefully pretty easy to see how this can become a lot of extra classes. Luckily, all these DTOs are pretty brainless to create as they are generally very simple Java Beans.
Just to expand on the architecture I chose (and have briefly and disjunctly discussed on the forum). Let me first suggest a great book on this subject, written by Martin Fowler, entitled "Patterns of Enterprise Application Architecture". It is extremely insightful, helpful and well written.
It seems that most of the discussion that I have seen on the forums regarding this topic relate to whether the objects mapped in Hibernate should be returned as-is to the clients, or whether some form of abstraction should be used to represent that data (whether XML, DTO, Commands, etc). To me, each approach has pros and cons. In my architecture, I chose the latter using DTOs as the communication medium with the presentation. In brief, my architecture is as follows:
1. At the bottom tier is a very strong domain layer (mapped using Hibernate). By very strong, I mean that it bundles all the data elements mapped from Hibernate along with a lot of domain logic (see the section discussing business logic vs domain logic in the chapter on the "service layer" pattern in Fowler's book)...
2. A set of DAOs with static methods for various methods of locating domain objects using HQL or session.load()
3. A service layer, implemented as session beans for no other reason than for the transaction support as I have to coordinate transactions across JMS, LDAP as well as the DB. This could easily be non-ejb also, possibly using aspects to acheive transaction "cross-cuts".
4. a set of "assemblers" (again, see Fowler) which are responsible for "molding" domain objects into DTOs and "swizzling" DTO data back into domain objects.
5. a slew of DTOs which carry data to and from the clients of the service layer.
To me, there are a couple of pros to this type of approach. Number one would have to be the fact that it completely decouples the client from anything that happens behind the service layer, and vice versa. Part of this is not having to worry about things like whether lazy relationships have been loaded when adding a new column to a search result table. Another advantage is that is gives your app a much more defined API feel. The methods exposed on the service layer are the functionality provided by the system to the outside world. And because a lot of the "nitty-gritty" code is hidden away in the DAOs and the assemblers, the service code is very clean. An example would be:
public ContactDTO loadContact( Long contactId )
throws my.PersistenceException
{
prepareCall();
try
{
return ContactAssembler.buildDTO( ContactDAO.load( contactId ) );
}
catch( Exception e )
{
throw new my.PersistenceException( "Unable to load contact", e );
}
finally
{
endCall();
}
}
The cons mainly deal with the fact that that's a lot of extra classes to code. At a minimum, in a small app, you can assume about a one-to-one correspondence between the domain objects in your app and their various DTO representations; this may be even bigger for larger apps. Why? Mainly it has to do with relationships and avoiding infinite loops. Consider a ContactDTO with a relationship to a CompanyDTO, which in turn has a collection relation to its employees which are ContactDTOs. This is normally handled by having different DTO representations of data with different "loading levels" (similiar to the Lightweight pattern discussed on the Hibernate patterns page). Thus, you now would have something like ContactDTO -> CompanyDTO -> ContactListDTO. And thats not even considering specialty DTOs like report DTOs, etc. Its hopefully pretty easy to see how this can become a lot of extra classes. Luckily, all these DTOs are pretty brainless to create as they are generally very simple Java Beans.
Monday, March 21, 2005
Development practices that could help make the software product popular quickly.
- rapid release schedule:Regular file releases (even a few days from one version to the next) were the best way to keep the project bug-free and users confident that the project is active. Having working software "out there", in actual use, is the best way to discover which functionality the users really need.
- regression tests: The importance of automated unit tests should not be underestimated. A comprehensive test suite is central to the maintainability and stability of any product, as it goes through massive changes in functionality and design. The mentality should be that if there is no test for a feature, then we have absolutely no idea whether that feature works or not.
- documentation: There's no such thing as an undocumented feature. If your users don't know about a feature, its a nonfeature. Get rid of it; it's just complicating the sourcecode.
- developer responsiveness: When users have problems, which they inevitably will, the development team must be responsive and helpful. Users let you know about holes in your documentation. Users find the subtle bugs that your test suite misses. And besides, the project is a waste of time without them. Incidently, heres a funny thing about bugs: users don't mind discovering bugs in new features, as long as they are fixed quickly. "Responsiveness" means bugfixes should be ready in under a week. 24 hours is a good target for the average response time between a bug report and the CVS fix.
Saturday, March 19, 2005
Friday, March 11, 2005
Junit vs TestNG
Junit Cons :
1. Each Test object is instantiated over and over again for every Test method.
2. Need to use statics to maintain any sort of state across invocations.
3. Relies on a static programming model which makes it difficult to run a subset of tests.
4. Have to start all your methods with 'test' and extend a base class.
TestNG pros:
1. Runtime configuration is in a XML file rather than a java source and so you can specify test groups and other relationships between tests. This allows useful stuff like being able to have a specified test run order, dependent tests (test X requires Y and Z to be run first). So for example, if you have some kind of 'verify db connection' as the first method, you can specify that all other tests depend on it, so once the first one fails, the others are not run since we've had an early failure.
2. The grouping support is quite powerful, since you can arbitrarily slice and dice your test into whatever groupings make sense for you. So for example, you can specify that a test is part of the 'functional' group, the 'config' group, and the 'database' group. You are then able to execute all tests within a particular group.
3. It extensively uses annotations (or JDK 1.4 javadoc comments) for metadata. The annotations available are a pretty rich set of controls to customize and specify test behavior. You can for example specify a timeout on a per test basis (if this takes more than 10 seconds, warn etc.)
Test NG Cons:
Tool adoption. For example with WSAD I can point at unit test class and use debug/run as a Junit program etc. Also there is this this JUnit EE that is a web application to test EJB modules that run inside the J2EE container.
1. Each Test object is instantiated over and over again for every Test method.
2. Need to use statics to maintain any sort of state across invocations.
3. Relies on a static programming model which makes it difficult to run a subset of tests.
4. Have to start all your methods with 'test' and extend a base class.
TestNG pros:
1. Runtime configuration is in a XML file rather than a java source and so you can specify test groups and other relationships between tests. This allows useful stuff like being able to have a specified test run order, dependent tests (test X requires Y and Z to be run first). So for example, if you have some kind of 'verify db connection' as the first method, you can specify that all other tests depend on it, so once the first one fails, the others are not run since we've had an early failure.
2. The grouping support is quite powerful, since you can arbitrarily slice and dice your test into whatever groupings make sense for you. So for example, you can specify that a test is part of the 'functional' group, the 'config' group, and the 'database' group. You are then able to execute all tests within a particular group.
3. It extensively uses annotations (or JDK 1.4 javadoc comments) for metadata. The annotations available are a pretty rich set of controls to customize and specify test behavior. You can for example specify a timeout on a per test basis (if this takes more than 10 seconds, warn etc.)
Test NG Cons:
Tool adoption. For example with WSAD I can point at unit test class and use debug/run as a Junit program etc. Also there is this this JUnit EE that is a web application to test EJB modules that run inside the J2EE container.
Crappy software
Installed RAD V6 (IBM® Rational® Application Developer Version 6.0 ) today. The software should be made synonymous with crappy. They should have a warning like this :
Do not install this if you have a heart condition, suffer from asthma, are afraid of the dark, or do not like to live dangerously. Your mileage, and performance, may vary. The irony of this is -- rampant bugs in this software -- which we already paid millions for-- force us to call the "support services" arm of said company, who then get to work busily fixing the bugs in their own product for whatever cost our support contract was paid for.
Do not install this if you have a heart condition, suffer from asthma, are afraid of the dark, or do not like to live dangerously. Your mileage, and performance, may vary. The irony of this is -- rampant bugs in this software -- which we already paid millions for-- force us to call the "support services" arm of said company, who then get to work busily fixing the bugs in their own product for whatever cost our support contract was paid for.
Thursday, March 10, 2005
EJB's: reasons to avoid
http://discuss.joelonsoftware.com/default.asp?joel.3.91272.13
There is a growing sentiment in book and non-book form that EJBs don't provide enough benefits for their considerable costs. Witness projects like the Spring framework and books like Rod Johnson's 'J2EE Without EJB' and Bruce Tate's 'Better, Faster, Lighter Java'. The only place where the benefits seem to outweigh the costs is with distributed transactions.
Some of the mythical benefits of EJBs:
1) 'You get declarative transaction handling'. This can be an OK benefit if your transaction needs are simple and straightforward (for example a single method is always a single transaction). If you want to start stringing together multiple methods into transactions (I can't imagine why anyone would need to do that) you have to start using certain design patterns to get around the limitation. At that point you may as well just do the transaction handling yourself because its not really that hard and you'll never have to spend the day trying to figure out what is wrong with your deloyment descriptors.
2) 'You get scalability'. People referring to this are usually referring to object pooling and the perceived notion that J2EE includes clustering support. The J2EE spec only makes mention of clustering support as a vendor specific add on. Most of them support it and they do it to varying degrees with varying levels of effectiveness. There is nothing in EJB that makes clustering easier - in fact it usually makes it much harder (what happened to my bean? why is it on server A when I want it on server B?) In regards to object pooling the only bean type that supports pooling are stateless session beans. Since the beans are stateless I can't really figure out what you get by having more than one of them. A simple singleton is an excellent replacement with none of the pool management overhead (I seem to have a reference to a non-existent bean. I guess I'll just write a whole bunch of call re-try logic - every time I make a bean call anywhere).
3) 'You get object persistence for free! FREE!!!' Entity Beans are just an all around bad idea. And a well documented bad idea too. See Bruce Tate's 'Bitter EJB' - he has a few chapters dedicated to why it's a bad idea.
4) Security. The only thing that EJB security really does for you is allow you to declare which application roles have execution permissions on which methods. Sounds nice in principle but in my experience it doesn't justify both the runtime costs and the configuration effort (get ready to trudge through a slew of XML files every time that you add/modify/remove a method). There just aren't enough methods where you are really adding security by saying 'These kinds of users can't execute this method'. Real authorization is often more complex than that and usually involves the data itself (user A can modify account number 123 but not account number 789).Don't neglect the costs of EJB usage either. There's a reson why EJB generates all of those classes for you. They're going to get executed. Every time you make a method call. You'll also pay some of the prices of remoteness even when most deployments don't involve remote communication. Sure you can use local interfaces if you know ahead of time that the call will be local - but there is still some overhead like JNDI lookups and whatnot. Why do a JNDI lookup when a method call will do?
The development costs are considerable as well. Configuration files can be an absolute nightmare - although there are tools to mitigate some of the issues. You'll start to wonder exactly what the point is when you're apending more time digging through XML than code. Server/application load times can be horrendous if you have more than a few beans. Not so bad for production but it's a real drag for development to wait 3 minutes for a server restart every time you want to test your code. But hey it's not like you do that 50 times a day or anything ;) And everytime all of the developers are sitting in a room trying to figure out just how it is that these classloaders are working. Count the number of times that you use the word classloader in your EJB world versus pre-EJB
There is a growing sentiment in book and non-book form that EJBs don't provide enough benefits for their considerable costs. Witness projects like the Spring framework and books like Rod Johnson's 'J2EE Without EJB' and Bruce Tate's 'Better, Faster, Lighter Java'. The only place where the benefits seem to outweigh the costs is with distributed transactions.
Some of the mythical benefits of EJBs:
1) 'You get declarative transaction handling'. This can be an OK benefit if your transaction needs are simple and straightforward (for example a single method is always a single transaction). If you want to start stringing together multiple methods into transactions (I can't imagine why anyone would need to do that) you have to start using certain design patterns to get around the limitation. At that point you may as well just do the transaction handling yourself because its not really that hard and you'll never have to spend the day trying to figure out what is wrong with your deloyment descriptors.
2) 'You get scalability'. People referring to this are usually referring to object pooling and the perceived notion that J2EE includes clustering support. The J2EE spec only makes mention of clustering support as a vendor specific add on. Most of them support it and they do it to varying degrees with varying levels of effectiveness. There is nothing in EJB that makes clustering easier - in fact it usually makes it much harder (what happened to my bean? why is it on server A when I want it on server B?) In regards to object pooling the only bean type that supports pooling are stateless session beans. Since the beans are stateless I can't really figure out what you get by having more than one of them. A simple singleton is an excellent replacement with none of the pool management overhead (I seem to have a reference to a non-existent bean. I guess I'll just write a whole bunch of call re-try logic - every time I make a bean call anywhere).
3) 'You get object persistence for free! FREE!!!' Entity Beans are just an all around bad idea. And a well documented bad idea too. See Bruce Tate's 'Bitter EJB' - he has a few chapters dedicated to why it's a bad idea.
4) Security. The only thing that EJB security really does for you is allow you to declare which application roles have execution permissions on which methods. Sounds nice in principle but in my experience it doesn't justify both the runtime costs and the configuration effort (get ready to trudge through a slew of XML files every time that you add/modify/remove a method). There just aren't enough methods where you are really adding security by saying 'These kinds of users can't execute this method'. Real authorization is often more complex than that and usually involves the data itself (user A can modify account number 123 but not account number 789).Don't neglect the costs of EJB usage either. There's a reson why EJB generates all of those classes for you. They're going to get executed. Every time you make a method call. You'll also pay some of the prices of remoteness even when most deployments don't involve remote communication. Sure you can use local interfaces if you know ahead of time that the call will be local - but there is still some overhead like JNDI lookups and whatnot. Why do a JNDI lookup when a method call will do?
The development costs are considerable as well. Configuration files can be an absolute nightmare - although there are tools to mitigate some of the issues. You'll start to wonder exactly what the point is when you're apending more time digging through XML than code. Server/application load times can be horrendous if you have more than a few beans. Not so bad for production but it's a real drag for development to wait 3 minutes for a server restart every time you want to test your code. But hey it's not like you do that 50 times a day or anything ;) And everytime all of the developers are sitting in a room trying to figure out just how it is that these classloaders are working. Count the number of times that you use the word classloader in your EJB world versus pre-EJB
Tuesday, March 08, 2005
Struts check box bug
When a check box is unchecked, the form bean property associated with the checkbox never changes from "true" to "false" or from "On" to "Off" based on the property type being a boolean or String.
Apparently this is a bug in Struts:http://forum.java.sun.com/thread.jspa?threadID=242031&messageID=2946045
On further research, found out that this is not really struts issue, but an issue with the mechanism of HTML form posting of check box values.
Apparently this is a bug in Struts:http://forum.java.sun.com/thread.jspa?threadID=242031&messageID=2946045
On further research, found out that this is not really struts issue, but an issue with the mechanism of HTML form posting of check box values.
Monday, March 07, 2005
Poblem stating
To master the art of problem solving, master the art of problem stating. http://www.jroller.com/comments/njain/Weblog/to_master_the_art_problem
The penalty for failing to define the problem is that you can waste a lot of time solving the wrong problem. This is a double-barreled penalty because you also don't solve the right problem.
The problem definition defines what the problem is without any references to possible solutions.
The penalty for failing to define the problem is that you can waste a lot of time solving the wrong problem. This is a double-barreled penalty because you also don't solve the right problem.
The problem definition defines what the problem is without any references to possible solutions.
Subscribe to:
Posts (Atom)