This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!

Maarten de Heus

Greenhorn
+ Follow
since Jan 30, 2006
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 Maarten de Heus

Hello Tong,

With authorization the idea is that you assign EJB method permissions to groups. Your system administrator can then create new users and place them into those groups. No need to redeploy your EJB's because the groups are stable.

In the deployment descriptor of your EJB use the <method-permission> tag to tell the server which roles are allowed to call which methods. For the roles you specify groups and not specific users. You then map the groups specified in the <method-permission> tag to real groups/principals you created in your J2EE server. This mapping is not specified in the J2EE spec so how this mapping is done, depends on the specific server you are using. In Bea WebLogic the mapping is done in the WebLogic specific deployment descriptor (weblogic.xml).

As for the external cache implementation. The J2EE spec. has some demands for the bean developer about not interfering with the container. Some of those demands: No messing about with the classloaders, do not use native libraries, do not use static variables. In cases where we were asked to break those demands, we created a separate JVM running the law-breaking code. We connect to the other JVM using RMI.

Most caching mechanisms are implemented using some Singleton pattern. (static variable which is also a nono). Run the cache in a separate JVM and connect via RMI. Do NOT implement the cache yourself but use some framework like JCache. The framework will handle the multiple calls.

hope this helps...

greetz,
Maarten
Hello Tong,

In this specific case (security/authorization) you should let the container
help out. For instance by using a connection to LDAP?

In other cases we implemented a cache outside of the J2EE container, running in a separate JVM.

greetz,
Maarten
Hello Geetu,

with the risk of a reply too simple, I'd say both; The java code is compiled into bytecode which is then interpreted by the virtual machine you run the program on.

greetz,
Maarten
13 years ago
JMS
Rai,

Communicating between WLS servers should not be a problem. You can use a WLS message bridge to "cross the gap".

MQ comes in when you need to talk to "other" applications written in Cobol or C++ , etc. running on other OS-es like a mainframe.

greetz,
Maarten
JMS
Hello Raj

The JMS API is indeed an interface. You will still need some implementation for it. A J2EE server must provide an implementation. But this will not always solve your problems.

The J2EE server's implementation of JMS will only provide you with queues within the J2EE server. When you need to communicate outside of your J2EE server you need some extra plumbing.

Websphere MQ is known for its multi-platform/multi OS implementation. If you need to communicate with lots of applications on lots of different OS'es, you might consider Websphere MQ.

At the company I work for, we use WebLogic in combination with Websphere MQ. For J2EE internal communication we use WebLogic JMS queues. When we need to talk to "outside" systems (like our mainframe or to systems from other companies) we use WebSphere MQ.

Hope this helps...

greetings,
Maarten
WebLogic supports something called virtual-directory-mapping. I think this is what you need. A quick search on google shows that other servers have similar functionality
13 years ago
From the description of your jar file I understand that you have a CLASSES folder containing a subfolder bean containing the classes. Is that correct?

You don't need the CLASSES folder (that's for wars).

greetz,
Maarten
Rohit,

WLS will put something in the log when it performs a deploy. When the deploy goes fine it will say something like; deployed Converter. When the deploy goes bad it will write an error messages.

When the log doesn't say anything, probably nothing has hapened. Make sure the autodeploy facility is on and your not running in production mode.

An other solution is to deploy the bean via the console; open de deployments section en then the beans section. Click on configure new EJB. Then select configure new EJB. Select your converter.jar and deploy it.

good luck !
>And i have made the .ear of the folder and deployed it inot the Autodeploy >folder.

1) ear file? I would think you need a jar file.
2) what does the WLS log say? When you copy something to the autodeploy folder, WLS tries to deploy it and will tell you if something goes wrong.