Chris Mathews

Ranch Hand
+ Follow
since Jul 18, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chris Mathews

Confluent (most prominent Kafka vendor) has a certification: https://www.confluent.io/certification
1 year ago
Our team has dropped estimating using story points. We just don't find it very effective... and instead estimate based on the largely taboo days. We allow the following scopes: 0 (why are we talking about this... just do it and be done), 1/2 day, 1 day, 2 days, 3 days, >3 days (not a specific number... just greater than 3 days). Anything greater than 3 days must be broken done into smaller stories... sometimes this will require a short spike to increase our understanding on this problem.

The problem that we have always found with story points is that it is just a relative concept based on a stick in the mud... and that stick in the mud tends to be a moving target over the course of a project.
A better question would be: What J2EE Design Patterns are still relevant?
This is definitely not going to work... nor would I ever recommend it. Using the technique that you describe above will get you JSTL 1.1.2 support but won't do anything for the other JSP 2.0 features (inline EL or JSP Custom Tags). I personally don't find JSP 2.0 all that compelling... though I use WebWork for Web Development (which relies on OGNL)

If you can't possibly live without JSP 2.0 then I would suggest you focus your energy on getting the powers that be to buy off on upgrading to WebLogic 9 instead of hacking WebLogic 8.1.
12 years ago
As far as Hibernate is considered we did a EJB vs Hibernate analysis and found out that performance for connection pooling and transaction management using Hibernate was not up to mark. Moreover in our design ORM was not as valuable as transaction management (so we chose Session EJB).

How did you make this comparison? Comparing EJB vs Hibernate is like comparing Apples to Monkeys. It doesn't make sense, EJB is primarily for building Distributed Components and Hibernate is an ORM tool... the use of one does not exclude the other. If you are saying that you compared Entity Beans to Hibernate then that is a valid comparison, however I doubt you would have made the conclusion that you did.

Let's talk about the two things you mentioned: Connection Pooling and Transaction Management...

Regardless of EJB vs. Hibernate, Connection Pooling can and should be managed by the Application Server. Both EJB (here I am talking about Session Beans using straight JDBC or Entity Beans) and Hibernate can use a JNDI Datasource which is created and managed by the Container.

Transaction Management is also a fairly trivial subject for the type of application you describe. I assume you only have a single datasource and no need for distributed transactions. This is the case in 99% of J2EE Applications and is actually fully supported by the standard JDBC specification... no need for JTA or XA Transactions, no need for EJB Transaction Management (though this makes transaction composition easier sometimes).

So basically what it comes down to is not EJB vs. Hibernate... but plain JDBC vs. Hibernate. This is a valid question and the answer really depends on your particular development needs. Do you have a Rich Domain Model with complex associations and little desire to hand-write SQL? If not then Hibernate probably isn't for you... however I wouldn't necessarily recommend going down the straight JDBC path either. Take a look at the Apache IBatis Project... it is a good mix of pedal to the metal SQL and ORM Mapping... at least I quite like it. Plus, as Stan mentioned, it is worth it to look into Spring for its abstractions on top of plain JDBC or even ORM tools like Hibernate and IBatis.

Finally, I would like to touch briefly on the subject of performance. It actually doesn't seem to me (based on your description) that this application needs much in the way of performance. In reality concurrent users is not a very good indication of total volume. What we actually want to know is the total number of concurrent transactions that the system will be processing. So let's take a shot at that metric with some concrete (and made up) numbers...

Number of Concurrent Users = 500 (shooting high here)
Average Think Time between Requests = 10 seconds (we need time to think before answering a question right?)
Average Transactions Per Second Per User = .1 tps (based on 10 seconds think time)
Average Total Transactions Per Second = 500 users * .1 tps per user = 50 TPS

So even being pretty conservative with these numbers, you are looking at 50 TPS. My thought is that the production volume will actually be much lower than this (ie. less users and probably a greater think time). As you can see, this isn't very high and I personally don't think you should be overly concerned about performance at this point in time. Put together a solid design, execute on it in build, and setup some time throughout the project to test performance and adjust the code as necessary. Rinse, Repeat.
[ April 27, 2006: Message edited by: Chris Mathews ]
I would also second Stan's comment on dropping the EJB layer. It isn't gaining you anything at this point.
This is a very typical configuration. However, if you want to have the user be able to type http://admin.ias.com and end up hitting http://www.ias.com:9004 you will need to configure either a hardware load balancer or a proxy server like Apache in front of WebLogic. You will not be able to do this with DNS alone...
13 years ago
It can... there are just certain scenarios that will produce code that if compiled as 1.5 will not run on 1.4/1.3. Likewise, some code compiled as 1.4 will not run on 1.3.
13 years ago
Make sure you are pointing to the weblogic.jar that is part of your 9.x install... not just a copy of that jar moved to another directory. There are a number classpath manifest entries that weblogic.jar has and uses during the execution of appc and I suspect they are not being loaded properly.

For example add the following to your build.xml classpath ref:
C:\bea\weblogic91\server\lib\weblogic.jar

See how that goes...
13 years ago
The of scenarios that could cause an OutOfMemoryException are pretty much beyond limit. We would need a lot more information to even begin considering the possibilities. My recommendation is to hook up a profiler to your application as quickly as possible to monitor the memory heap and the types of objects the are causing it to grow.
13 years ago
The developer has to cast the return object from the ServiceLocator anyways right (ie ServiceLocator returns a SuperInterface or Object)? Just have the developer pass in the home interface.

Client Code:


ServiceLocator Code:


This is the standard way of solving the ServiceLocator problem for EJBs. In my example I left out exception handling and caching of EJBHomes... but I am sure you get the idea.
Checkout this post from the EJB Forum.
13 years ago
The left frame was just not refresh... happens from time to time in the weblogic console. If you just hit the browser refresh button it will force the left frame to properly refresh and the application would have disappeared completely from the console.
13 years ago
Hi Sunil, Welcome to JavaRanch! I will happily send you the code that you speak of, we are just have to work out a couple details...

1) What exactly are you trying to do? I have no idea what PictureTalk is nor do I have any clue as to how someone not knowing anything about your application will integrate with it.

2) How much are you going to pay me?

Seriously, none of us are here to "give" someone code solutions. We are all volunteers that are trying to help others work through questions and problems they might have with Java/J2EE or anything else. Whether you meant it or not, it is quite insulting to jump on a forum full of strangers and ask them to do your job.

That said, we are still very opening to helping and if you would like to provide more details and put in a little effort we might be able to work this out...
ApplicationContext does more than a simple BeanFactory. Despite the claim, the memory difference will be insignificant... certainly not a reason to use one over the other.