Edy Yu

Ranch Hand
+ Follow
since Nov 21, 2000
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Edy Yu

This question has been asked for years but is still bothering me

Environment:
WSAD 5.1.2
Test Environment 5.1

I have a xerces.jar (Xerces 1.4.0) included in my EAR. This xerces is used by an EJB to parse some XML documents. I set the classloading policy of the EAR to be PARENT_LAST and MODULE to make sure my xerces is picked up. This works for the EJB XML parsing part.

However, after I added web services interface based on that EJB, the web service won't work because my xerces is not compatible for the new web services. I switch to PARENT_FIRST, web services work but not my EJB XML parsing.

Articles on this issue alwasy deal with using xerces in WARs, not with EJB cue there is no such setting for EJB (unlike WARS, you can use its own classloader mode).

I think this must be a common issue. Anyway to work around it?

Thanks in advance...
18 years ago
For a method in my EJB interface defined as get_name(), in the EJB_mapping.xml,


<service-endpoint-method-mapping id="ServiceEndpointMethodMapping_1115045188398">
<java-method-name>get_Name</java-method-name>
<wsdl-operation>get_name</wsdl-operation>

... ...

the first letter after the underscore is capitalized. This results in an error at run time ( or maybe deployment time ) because the web services engine cannot find the corresponding Java method.

Is this a known bug of WebSphere Studio? Is there a way to get around it?

Thanks in advance ...

[ May 02, 2005: Message edited by: Edy Yu ]

[ May 02, 2005: Message edited by: Edy Yu ]

[ May 02, 2005: Message edited by: Edy Yu ]

[ May 02, 2005: Message edited by: Edy Yu ]

[ May 02, 2005: Message edited by: Edy Yu ]

[ May 02, 2005: Message edited by: Edy Yu ]
[ May 02, 2005: Message edited by: Edy Yu ]
18 years ago
Gurus here:
We are planing to cluster a few WebSphere 5.1.1.2 instances to achieve loadbalancing and failover. Providing the apps we are going to deploy are all "stateless and simple", what should I put in consideration while selecting the topology and installing our apps? I want to start with simple approaches first.

Any pitfalls. Practical experience will be highly appreciated

Thanks in advance
18 years ago
Created a simple Stateless Session Bean and trying to generate web service

Got this error when lauching the Web services test page.

WSWS3345E: Error: Unable to locate a valid EngineConfigurationFactory.

Please advice.

Thanks in advance ...
18 years ago
The dpl_....ear should be a temporary file created by WebSphere when deploying. For some odd reason, it cannot be created in my environment.

Any WebSphere 5 guru's here???
18 years ago
I've got a J2EE 1.2 EAR which has an EJB module, two Web modules and a bunch of utility JARs.

Right now, I am trying to deploy it through the web based admin console of the 5.1 test server (bundled in WSAD).

Here is the exception I got:

com.ibm.etools.archive.exception.OpenFailureException: IWAE0037E Could not open C:\DOCUME~1\yuxia\LOCALS~1\Temp\app_10341a6bded\dpl\dpl_MyProductEAR.ear

My EAR is MyProductEAR.ear.

Any ideas why?

Thanks in advance.
18 years ago
I agree with Stan's opinion, even though we still need to think carefully about the thread synchronization issue in a distributed environment because of the possible multi-JVM, multi-container configuration in which the sychronization may not work as expected.

Damanjit Kaur, I think you confused thread synchronization with entity state synchronization. Two different concepts.
[ February 03, 2005: Message edited by: Edy Yu ]
Thanks for your reply.

However, you stated just what a thread synchronization is about. Not specific to the container controled enviroment.

According to the spec:
"An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances."
"This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean�s instances, others may distribute the instances across multiple JVMs."
"Synchronization would not work if the EJB Container distributed enterprise
bean�s instances across multiple JVMs."

This is understandable because of the EJB's distributed nature. However, if we sychronize methods of POJOs (some people call them utility classes in the container), should not we consider the same premise as the spec reasoned?
I understand (according to EJB spec), sychronized key word is prohibited on EJB's methods. The reason for that is not very clearly stated in the spec. Anybody can help me understand it?

How about on the methods for POJOs in the container? Can we put that key word?

There are some confusions on this topic when I talk to J2EE developers. Some of them just totally avoid using that in their project since u think EJB spec says so.

But I think differently ...
Primary Key is a must but primary key class is not. You can certainly have a primary key defined as String...
is there a way in WebLogic to see the container generated code?

I know in WebSphere Studio, you can ...
No.

As a enterprise application, you would have this hirarchy:

-YOUR ENTERPRISE APP.EAR
- YOUR WEB.WAR
- YOUR EJB.JAR
- DTO.JAR
Put DTO jar under application level and treat it as a utility jar ...
BMT -> CMT -> BMT

First, it's not possible to propagate your TX context from CMT -> BMT as BMT always starts a new TX. This means that you have to suspend your CMT TX before entering BMT ... (nested TX is not supported ...) So, be careful of the possible behavior.

Second, from BMT -> CMT, if you want to propagate your BMT TX to CMT, you can't set ur CMT TX attr requireNew ...

Overall, this mixed design poses some potential difficulties and should be avoided ...

My 2 cents.
For those plain Java classes running in a app server, how would we distinguish them between running inside the web server and running inside the EJB container?

This question will bring a further question which asks for the JNDI naming context for a regular Java class.

Thanx in advance.