Terry Mullett

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

Recent posts by Terry Mullett

You could store a lighter-weight object in the session, a sentinel, that implements the listener interface and can identify the object being stored in the singleton. When the session expires and the sentinel is unbound, it's valueUnbound callback method can alert the singleton to get rid of your heavyweight object. A little roundabout maybe, just the first thing that occurred to me.
Have you checked out javax.servlet.http.HttpSessionBindingListener?
Deafening silence

Someone on our team did find a blurb in a release note (for ejbtools, I believe) stating that deferred primary keys are not supported. That's not the same thing as far as I'm concerned, but I'm taking it as an indication that any PK monkey business outside the 2.0 spec won't work.

I did try messing about with the generated RDBSchema files and got a few things going, but it was turning into such a big hack that I just turned back. Looks like a job for BMP....
20 years ago
Folks,

I'm trying to figure out how to make the following work:
1 - CMP entity bean
2 - table is in MS SQL Server
3 - primary key is an IDENTITY (auto-increment, can't write to it) column
4 - server is WAS 5.0
5 - dev environment WSAD 5.1

I can't seem to find any way to get WAS to buy into the auto-increment key. I'm finding lots of references to Weblogic and JBoss methods for this, but none WAS. Does anyone know whether WAS does this, or whether instead I'm wasting my time?

Thanks
Terry
SCEA/SCBCD/SCWCD/SCJP
20 years ago
A thing can be "compliant" with a normative specification (such as the J2EE spec) and "compatible" with an implementation (even a theoretical one) of that spec. Servers are compliant to some degree, and applications are compatible to some degree.

So what about all that stuff in the specs regarding the developer's role, or programming restrictions? Those just describe the developer-facing aspects of a compliant server. It's still a server spec.

So when somebody says their application is J2EE compliant, you should read that to mean that it will behave well in J2EE-compliant servers. Speaking more strictly their application is J2EE compatible.... that's splitting hairs, though. Doesn't sound like anything to have an aneurism over.
The problem is that the word "client" is overloaded. "Client" in the sense that you quote/paraphrase in the beginning is a relative term. Any object A calling a service on object B is a "client" (and B is a "server"). This is not to be confused with "client tier".

Is the EJB framework too complex? Depends on the overall complexity of your application. Managing concurrency, transactions, security, and (as your lead-in suggests) distribution transparency is also complex if you try to build it from scratch. EJB could be a complexity bargain if you need those things. If not, it could be a boat anchor. And that's what you, as an architect, would decide -- case by case.

Cheers,
Terry
SCEA/SCBCD/SCWCD/SCJP
I'd start with the Cade/Roberts book "Sun Certified Enterprise Architecture for J2EE Technology Study Guide" and the blueprints book "Designing Enterprise Applications with the J2EE Platform 2nd Ed". Branch out from there to the subjects you feel uncomfortable with. I wound up going into the Java Tutorial trails for internationalization, RMI, IIOP and platform security to brush up on those areas. You should have a good grasp of GoF patterns for part 1, as well. I haven't seen the sort of drill&practice material for this cert that can be found for the programmer/developer certs. This is appropriate since this cert is is less about factual matter and more about guidelines, principles and judgement.

Good luck,
Terry
SCEA/SCBCD/SCWCD/SCJP
Nope, sorry. Or at least, not in a vendor neutral way. Bean-isms, endowed by the container, aren't inheritable, and don't have any connection to what your bean implementation class has going on with Java inheritance.

Terry
SCEA/SCBCD/SCWCD/SCJP
Ilja,

Well personally I find that testing helps me discover when my initial ideas weren't as good as I'd like. Perhaps the methods should be "top level abstractions", even if I didn't initially think of them that way...



Indeed. Unit testing really makes you take a hard look at your design, and I will definitely tweak designs based on insights gained during test writing. I do try to be careful not to take it too far because changing a design to get around a hard testing problem could make the design unnecessarilly complex, or compromise it's conceptual integrity by introducing distractingly incohesive public classes/methods into the api. It's a tradeoff like anything else. Still, the exercise is valuable, because even if I don't or can't change the design, working through the question sharpens my abilities.

Terry
SCEA/SCBCD/SCWCD/SCJP
20 years ago
Nigel,

"There's no point in testing this function, the requirements have been changed and it wont be used anymore. If I write unit tests for everything used and unused I'll be here forever."



And, of course, if the unit tests were written and passed while the code is being written this wouldn't happen either... the tests would already be there.

Where I'm at, unit tests are mandated, and since we brought in jCoverage they're somewhat managed. We're still tweaking this, and haven't arrived at a really solid philosophy about it yet.

The biggest problem I've seen is that testing's a different discipline from business logic coding, and not all developers "switch hats" so comfortably. Some seem to enjoy it. Others do experience some discomfort when they switch contexts, and if you let them they'll slip into a pattern of coding for weeks and then going back to do the unit tests when coverage hits the lower control limit.

Second biggest problem I've seen is attitude. I know developers who just plain don't want to do it, and are happy enough when something comes along that pushes testing off the agenda. You can evangelize up to a point of diminishing returns, and then it has to come down to policy. At least, that's what we discovered. It works that way for lots of things, doesn't it?

Terry
SCEA/SCWCD/SCBCD/SCJP
20 years ago
Vinicius,

A lot of time the best value I get out of testing is the way it makes me question my design. The original code you posted had the two public methods looking like a functional decomposition of the public method that called them. In this case those two private members were only marginally "members" -- members by convenience of structure, rather than by design intent. Lasse offered a solution that would look like a strategy pattern with a bit more tweaking, and if the classes that replaced those methods had package visibility I'd say you could be done. But then comes the question: are those two methods really top-level abstractions in your mind (in which case promotion to classes could make sense) or are they just pulled out into separate methods to control ugliness (in which case promotion to classes is departing from your desing intent)? The answer to this question should also tell you whether to bother testing those methods directly, or to cover them as side effects of exercising the public method.
20 years ago
flowcharts?

Only reason I've seen (and sorry, can't remember a source to quote) is that flowcharts are "procedural" while OO concentrates on the responsibilities and collaborations of objects. Seems like a narrow vision, since so many applications automate some sort of process.

I think that sequence and collaboration diagrams are fine for illustrating how a part of a process is achieved by a set of objects, but that's all implemetation-space and you have to get there somehow. Getting there often requires detailing what that process is. You might take a look at activity and maybe state diagrams. In some quarters activity diagrams are also considered non-OO.

But really isn't modeling about exploring, clarifying and communicating ideas? Whatever accomplishes that mission best is what I'd use.

Cheers,
Terry
SCEA,SCWCD,SCBCD,SCJP
Agreed, this is a book any professional Java programmer should use. I'm hoping there will be an update for Java5
20 years ago
I've used POI on the job and it works great. It does (or at least did when I last used it) model the Excel format fairly directly, which requires that the developer needs to have some cognizance of how Excel stores data. Excel has a pretty crappy format. But once you understand it, POI's not hard to use.

Another option that works well if you're using spreadsheets as input is to have your spreadsheets saved as XML and then use XPath (or DOM or what-not) to navigate to the pieces you want to work with. That's pretty slick if you can hand out an input template with named sheets, named ranges and sheet/workbook protection, because there will be XML elements that help you identify cells semantically. As far as I know, saving as XML can only be done with Excel XP/2003.

Regards,
Terry
SCEA,SCWCD,SCBCD,SCJP
20 years ago