Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!

Denis Wang

Ranch Hand
+ Follow
since Jan 23, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Denis Wang

Do you mind to share your sample code here?
I run into the same issue and look for a solution now.
12 years ago
I'd be surprised if people are still struggling with Grails + Legacy Database. This link provides very easy to use sample code and straightforward tricks.
12 years ago
I need to open a big file, insert one line at the beginning of it. What is the efficient way to do it?

17 years ago
Thanks for your kindly reply. However, i missed one point in my previous message. (Otherwise your code will definitely work.)

My schema includes another common schema, which is also located in the jar file:
<xs:include schemaLocation="FQ-Common.xsd" />

How to handle this situation.

Hello, all,
I use the following code to access my schema
URL schemaURL = getClass().getClassLoader().getResource(schemaString);
parser.setProperty(JAXP_SCHEMA_SOURCE, schemaURL.getFile());

This code works fine in my IDE. But when i deploy the project and jar up the xsd file, this code returns null exception.

When I print out the schemaString, it looks like:

Any ideas how to resolve this problem?
thanks a lot!
Hello, all,
I use the following code to access my schema
URL schemaURL = getClass().getClassLoader().getResource(schemaString);

This code works fine in my IDE. But when i deploy the project and jar up the xsd file, this line returns null.

Any ideas?
thanks a lot!
As to Arc2Patterns, I can only say,
the Part I materials are helpful only if you trust your own judgement instead of their answers.
the part II materials are just garbage.
Class Diagram (44 maximum) .......................... 37
Component Diagram (44 maximum) ...................... 34 Sequence/Colloboration Diagrams (12 maximum) ........ 7

Even though the score is not that good, I am still very happy to marginally pass. Really appreciate the forum here.

I tried to finish the assingment in 1.5 month with a full time job.

Other than this forum, I do find the book from Mark Cade very helpful, without which I could not have finished the assignment in such a short time.

thanks a lot. very interesting.
another option is to enhance the FF system with web services support in addition to it's http/html support.
thanks for a lot of good replies. I didn't explain clearly previously.
Choice one: SFSB
Good: if hundreds of concurrent invocation, activation/passivation can be used to save memory usage at the expense of I/O operations.
Bad: the burden is centralized in ejb server.
Choice two: HttpSession or session cached in GUI client
Good: the two web servers and the GUI java clients will share the burden for caching status
Bad1: No mechanism in servlet to activate/passivate HttpSession
Bad2: session replication is a problem. considering the nature of a ticketing system, session failover will not be supported. (Anyway to lose a booking status in rare cases is not a disaster.) all requests from the same IP will be routed to the same web server. there are other tricks to walk around this limitation.
It's your choice.

Originally posted by Chiang Guo:
Thanks for your good points!
Another point I think is SFSB would be better for controlling transactions, though servlets could also do transaction.

transaction control and conversational status are totally independent, as far as i know

Originally posted by Bharat Ruparel:
May be I am missing something, but I don't think we have a choice. The Agents are supposed to have a rich-client interface and the customers are supposed to have a thin-client interface. If you maintain your state entirely in the HttpSession, interface for the agents? Are you designing your sytem so that you don't maintain any state at all for the business-tier in case of the rich-client application interface?

ejB tier: stateless
presentation tier {web app. server & rich gui): maintain states
browser=>web app=>ejb
gui => ejb
this is an interesting topic. You have the following choices:
1) no session state cached anywhere other than a sessionId in a cookie or embeded in url. end user re-submit all information again and again for the following requests. it is something like, when you are in phone call with somebody, everytime you say something beginning with, 'this is denis speaking, previously we just talked about step1, now i am going to talk about step2."
2) cached in web application using HttpSession
3) cached using stateful session beans
4) write it into database (or any permenant resource)
There are cases when 1) and 4) are definitely better choices.
Now let's just suppose you DO HAVE to cache your conversational status either in web layer or ejb layer.
httpSession is a straightforward solution with serialization. Stateful session beans are heavy because they have services for transaction, security, instance pooling, and etc. why not split their functionalities into two parts: httpSession takes care of the state-caching part and stateless sessionbeans take care of the transaction, security....
I have no clue why the author of the article make the following comments:
"Indeed, it seemed that the use of stateful beans should actually improve performance, since we would no longer need to wear the cost of serializing state relating to the application transaction to and from either the web tier or database upon each request."
Is activation/passivation coming free? Anyway the bottom line is stateful session beans have to use techniques similar to serizalization to cache the state if memory is not enough when hundreds of users hit the server simultaneously.
Forgive me if i am biased. Once I switched stateful ones into stateless ones to boost performance dramatically with weblogic6.1. i'd rather trust my real experience.