Gladwin Burboz

Glenn Puckett wrote:This is the very reason I am reluctant to have ANY links to external sites that my production level application requires. It's great until that company has a policy change or goes out of business. No, everything from jQuery to dtd's go on my own directories where I KNOW they will be there tomorrow and the next day and every day after that as long as my website is operational.

This change does not directly impacts any existing deployed production systems as required DTDs are bundled with respective JARs.
Changes listed above are done only to satisfy eclipse IDE and there are also other work around to do same.

Jonathan Lewis wrote:Per the struts user group: Public files have been re-hosted here: (xwork dtds should be put up there soon....not yet though)

http://struts.apache.org/dtds/

New URL works for us !!!.

Now OpenSymphony has seen it's final days. All xml have to change the dtd to struts.apache.org. xworks related DTD's have been uploaded on "2011-06-02 17:47"

In eclipse you will get below mentioned error which can be resolved as specified by this solution.

Referenced file contains errors (http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd)


E.g. To fix your validation xml files.

Old way of validation DTD

<!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd">

Replace with New validation DTD

<!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" "http://struts.apache.org/dtds/xwork-validator-1.0.2.dtd">

I know this thread is very old but didn't find any satisfying answer and hence adding few comments.


http://download.oracle.com/javase/1.4.2/docs/guide/intl/encoding.doc.html
In Extended Encoding Set look for "Cp943" - "IBM OS/2 Japanese, superset of Cp932 and Shift-JIS"

Make sure your JVM has required charset in "jre\lib\charsets.jar"
Use IBM JRE which will mostly have this extended charset for Cp943

InputStreamReader isr = new InputStreamReader(fileInputStream, "Cp943");
Thanks,

Gladwin
[http://www.linkedin.com/in/gladwinb/]

1. onMessage (with Required attribute) calls other bean (with required also) where other bean gets a system exception.
Result : Other bean is discarded, MDB Transaction is rolledback and same message will be redelivered to onMessage method again.

CORRECT

2. onMessage (with Not_supported attribute) calls other bean (with required ) where other bean gets a system exception.
Result : Other bean is discarded, what happens to MDB? What it throws? Is the message redelivered to it again or is it simply discarded?

Since MDB has transaction NOT_SUPPORTED, auto commit happens as soon as message is picked up by the listener even before calling omMessage(). By the time system exception occurrs in other bean, message is already commited and hence will not be redelivered.

3. onMessage itself throws a system exception.
Result : MDB is discarded, it throws this system exception to container.

If MDB has transaction NOT_SUPPORTED, message is already commited and hence will not be redelivered..
If MDB has transaction REQUIRED, message is will be redelivered..

4. onMessage itself throws ApplicationException???
Result : ???

Application exception does not cause transaction to roll back hence message will not be redelivered..

5. i set context.setRollBackOnly explicitliy on onMessage method with required attribute.
Result : ???

MDB has transaction REQUIRED attribute hence transaction will rollback and message is will be redelivered..

It dosen't matter what the message producer is. Once the producer commits the message, it will appear on the queue.

In scenario that you described, as Aryan mentioned, all DB trasactions would be rolled back and the message would be redelivered. This is because global transaction is rolled back when database update fails and hence all the participating transactions rollback.

What you need to watch out is if everything goes fine and call to onMessage() method successfuly completed. Here you have two or more resources involved in this scenario (JMS/DB). At this point cointainer will start to commit transactions on each resource. If we have say two resources viz R1(JMS) and R2(DB), first container will commit resource R1 and then resource R2 (order is not garaunteed). Now if something goes wrong while container is performing commit on resource R2 then it will rollback, but resource R1 is already commited.

If you are using XA drivers for your transactions, only then will container take care of this scenario and gaurantee commit all or none for all the XA resource transactions that are participating containers global transaction.

For more info please read on 2-phase commit and XA transactions.

You can use a role name declared by a <security-role> rule as a parameter to the isUserInRole() method. For example, with the following snippet of a web.xml entry:

<servlet> <servlet-name> secret </servlet-name> <servlet-class> SalaryViewer </servlet-class> <security-role-ref> <role-name> mgr <!-- name used by servlet --> </role-name> <role-link> manager <!-- name used in deployment descriptor --> </role-link> </security-role-ref> </servlet> <!-- ... --> <security-role> <role-name> manager </role-name> </security-role>

The servlet secret can call isUserInRole("mgr") or isUserInRole("manager") -- they will give the same behavior. Basically, security-role-ref acts to create an alias, but isn't necessary. That is what you'd naturally expect, but the API 2.2 specification could be interpreted as implying that you could only use roles explicitly declared in a <security-role-ref> alias rule. (If that doesn't make sense to you, don't worry about it; just be aware that things are now guaranteed to work as they should.)

Reference Article: Servlet 2.3: New features exposed , see - DTD Clarifications

http://en.wikipedia.org/wiki/Decorator_pattern

It is used to decorate HttpServletRequest object

See Decorating Servlet Request Objects

See tutorial on Lock Object (http://java.sun.com/docs/books/tutorial/essential/concurrency/newlocks.html) ...

Apurva Goyani wrote:
Hi Gladwin,
I agree to what you said, but just one question ponders me is that when two threads have access to two methods (1 static and other non-static respectively) simultaneously how it will access static field (val from StaticSynchronizedDemo), won't it will lead to violation of integrtiy?

You can synchronize access to this variable using synchronized block that should attempt to acquire lock on class object as shown below.

synchronized(StaticSynchronizedDemo.class) { // Code that will access static shared variable }

However if you are using Java 5 or above, it will be wise to use Lock object instead.

Two different threads cannot access synchronized static method of a same class as one thread will first get the monitor of class object instance.

Also if there are two threads as below
T1. Thread that has acquired lock on an object instance say O1
T2. Thread from synchronized static method which will attempt to access non-static field using object instance O1

T2 has acquired lock on class-object instance and not on object instance O1.
When T2 attempts to access O1, it will see that O1 is already locked by T1 and will get blocked.

And T2 should acquire lock on O1 as follows:
synchronized(O1) { // access O1 variables here }

Lock is the feature of an object, not of a method or a class or a thread. Thread that needs exclusive access to a particular instance, acquires lock of that object by using synchronized method or a block.

For a given class, you can have multiple object instances each having it's own lock.
For a given class, you can have one and only one class-object instance having only one lock.

Thread acquires lock of an object instance or class-object instance.
Only one thread can acquire lock of a given object at a time.

Thread calling synchronized instance method will acquire lock on that object instance.
Thread calling synchronized static method will acquire lock on class-object instance.

Having said above,

if thread acquires lock on one of the object instance of a given class will not prevent some other thread to acquire lock of a class-object instance

.

I have just started to prep for part-1 of the exam. Here are few inputs from me based off reference from SCEA book by Cade/Sheil

Integration tier services abstract and provide access to external resources.

Drivers and APIs that you use to access this external systems will be considered as part of this tier. If you develop some API whose sole purpose is to provide access to external system, then it can be considered as part of this tier. If your SSB is a generic API that you have developed that can be used to invoke any web service then you may consider it as part of integration tier.

Business tier services execute business logic and manage transactions.

SSB does provides ability to manage transactions. Further more if SSB API is specific web service related to your SuD, I would consider it as part of business tier.


Proxy is used to control the access to original object. Adapter is used to provide interface known to the client of an object whose interface is not known to the client. Hence I would consider your SSB to be an adapter instead of proxy as it adapts web service interface to EJB based interface.

raj sirohi wrote:Hi,
I confused about the interface needed for ejb 3.0 for clustering. my question is if I have three seperate application servers on three different machines ( each running ejb container and web containre in same jvm) then can i just use local interface for ejb for clustering.

any thought please!

thanks
Raj

If you use local interface, you can benefit from clustering for incoming HTTP request from the client. However, your calls to EJB will be limited to same node on which you received the request from the client.


If you use remote interface, even you EJB calls will be distributed across the cluster.

There are two transactions happening here
T1: The application performs an insert (inventory database), then put message on JMS
T2: The message-driven bean performs an insert (sales database), using JMS message from the queue

A. The message-driven bean does not perform an insert, the application does not perform an insert.

VALID:
T1: T1 insert fails then T1 rolls back, so message is put and appears on queue
T2: Message will not be available to T2, so no insert will happen

B. The message-driven bean performs an insert, the application performs an insert.

VALID:
T1: T1 insert successfully completes, so message is put and appears on queue
T2: T2 reads message and successfully completes

C. The message-driven bean does not perform an insert, the application performs an insert.

VALID:
T1: T1 insert successfully completes, so message is put and appears on queue
T2: T2 reads message and tries to insert but fails

D. The message-driven bean performs an insert, the application does not.

INVALID
T1: T1 insert fails then T1 rolls back, so message is put and appears on queue
T2: Message will not be available to T2, so no insert will happen. Hence invalid.



The question is

"Which statement cannot be a valid outcome of this transaction"

Answer is "D"

You can get NullPointerExecption at line 5 if m_handlerRef is null