Win a copy of Java Challengers this week in the Java in General forum!

Pradeep Ram

Greenhorn
+ Follow
since Sep 29, 2004
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 Pradeep Ram

http://edocs.beasys.com has most of what you are looking for. Usually for iPlanet, the following is the process

Plugin for NES/IPlanet is provided as .so file.
Copy it to the iPlanet's server /bin directory.
Edit obj.conf to forward certain requests.

Hope this helps.
You may want to seperate the web layer(iPlanet) and the app server (WLS) physically (different) boxes for security reasons. I am not sure if the plugin would work better if WLS and iPlanet were co-located on the same box. They would probably use local IPC instead of sockets, but I am not too sure. But the rule of the thumb is seperate the web and app layers and have images and static content hosted on iPlanet.
16 years ago
I am using WLS 8.1 SP3 on a Solaris box with JDK 1.4.1_05. We are using the perimiter authentication in WLS. All the web resources of the application (*.jsp) are protected using a Form based authentication. When a resource is invoked, Weblogic determines if the person has signed on to the app, if not, it throws a login page to the user. The problem we seem to have is that the Weblogic does not seem to disconnect the connections once the authentication process is complete. i.e. When we run a netstat on the LDAP box, the connections from the Weblogic server is always 'ESTABLISHED' and it never seems to time out. I have scoured the documentation looking for a setting that would force WLS to disconnect either after a successful or a failed auth. Has anyone else experienced such a problem ? Is there a patch for this ?

Thanks in advance
Pradeep Ram
16 years ago
If you are using Axis, try to use TCPMon (TCP Monitoring tool) to look at the SOAP messages that were formed at your end. This would help you diagnose message related errors.

Its a little difficult to diagnose the problem from the error message, it appears that there is some kind of casting problem. Unfortunately the faultActor attribute is empty, so we have no clue as to who caused the problem. Try to run a debug tool against your application to see where the request fails.

Are you using handlers and chains for this application ?

--Pradeep
16 years ago
I have done a similar implementation of refactoring 'magic sfsb'. But in my case, there was only one transaction. I had written POJO (helper) classes for such a scenario, where the funcitonality (processing) was delegated to helper classes to keep the bean code cleaner. I wouldn't say we achieved significant performance increase, but the purpose of refactoring was to increase reusability.

We had reduced 1 sfsb to 2 slsb, and we had chained the slsb for some of the requests. I am not sure if you can chain your requests, but keep the methods that are involved in the same transaction within a single bean.
My 2 cents .. One of the primary reasons to use EJBs in webservices is, if you have a service available that is implemented using EJBs (say like a StockQuoteBean), if you need to expose this EJB to outside customers, you can expose the Bean as a WebService.

If you are planning for transactions using webservices like a OrderManagement system or TicketReservation, then you need the container benefits like Transaction/Security, then EJBs are a natural choice.

Or if you prefer the lighter frameworks, Spring will do the job for you.
--pradeeP
16 years ago
Does your webapps directory have "webapps/axis" directory ? Did you step in the 'axis' directory and see what the contents were ? Create a new file like test.html and then invoke it. If you invoke HTML , Tomcat should manage it as it does not involve any Axis libraries, its a simple WebServer request. If that does not work. Go to "tomcat\conf" directory and in server.xml try to add theis line

<Context path="/axis" docBase="axis" debug="0"/>

The Webapp folder should be called 'axis' (lowercase) .

--pradeeP
16 years ago
Looks like your WebApp conked out, re-create your WebApp that runs axis and make sure your WEB-INF/lib has the right jar files. If the WebApp is not able to find HttpServlet, then the WebApp is not able to access the tomcat's library files (common libraries like servlet.jar)
--pradeeP
16 years ago
Sachin,
What operation are you trying to invoke that gives you NullPointer exception ? What style are you using RPC/Document/Message ? I have generated the stubs from the WSDL, could you give me some sample paramters, I should be able to run and test it.
--pradeeP
16 years ago
Sachin,
The simplest way to get the mapping is to obtain the WSDL for the webservice that you want to post to, and run WSDL2Java on that file. Look at the interfaces and stubs that it creates, it will help you identify Data type mappings.

From the Axis documentation it appears that when there is an element or a nattribute without any type it defaults to xsd:anyType.

One other thing is that open the XXXBindingStub.java that Axis generates, locate the addParameter() where you are passing xsd:anyType and try to change the mapping to Array.
--pradeeP
16 years ago
Did you try to lookup any other bean from the JNDI Context. Your mapping seems ok. Try to prefix the call with java:comp/ before providing the JNDI name.
--pradeeP
The fact that EJB 2.0 supports local interfaces does not mean that all calls to beans would be through local interfaces only. There would be situations where you might have to deal with remote interfaces (especially when your EJB container is clustered and the client/bean are not in the same VM).

With the advent of local interfaces, Session Facade still retains its value as a business layer to consolidate calls to entity beans. Though you have local interfaces, I think coarse grained objects are still a better way to send information from the facade to the client.

You would have to make a call on whether you want to use composite entity pattern or not. There is no wrong way, choose what you feel is appropriate for the situation.
So long as you read data from a URL, the EJB spec does not have a problem with that. Try to use the following to help you achieve the solution
1. Try to have atomic URL calls (not a multi request-response back and forth communication). You can have a URL call to a server to read the stock quote, parse the response and send it back to your client.
2. Even better have a POJO to do this job, so that your bean code appears cleaner.
3. If you need timeout for your connection try using the HTTPUtils class in the apache soap implementation (I think the package is org.apache.soap.util.net , I am not too sure though)
4. Check to see if your appserver is not in a DMZ (De-militarized Zone). If it is you need to open ports in firewalls, also find out if you need a proxy for outgoing connections.
5. From the 'Best Practices' perspective the connector architecture would be a good bet, but I think it might be an overkill for something as small as a stock quote fetch (But will get you kudos from your application architect)

--pradeeP
Hi Tarun,
Try to prefix the lookup call with a "java:comp/". This could solve your peoblem.

initial.lookup("java:comp/env/ejb/XMLMsgs");

Let me know if this helps.


--pradeeP
Gus,
When you refactor the code try to keep the interfaces as distinct as possible between the 3 SLSBs that you are going to create. Effectively, the load will be balanced amongst the 3 beans.

I am not sure if you have any transactions associated with the SFSB. If you do, how you decide to split the transaction amongst the new beans will be a good place to watch for potential problems.

Just curious, if you had a SFSB earlier, how are you planning to store state based information in the SLSBs ?
Gordon,
I don't think I have yet got a full grasp of the scenario that you have been experiencing. This problem that you might be experincing could be specific to an Application Server. Since you are using non-transacted messageds, use a JMS Connection factory that is configured NOT to use XA. If you happen to be using Weblogic this URL (http://e-docs.bea.com/wls/docs81/ConsoleHelp/jms_config.html#jms_connection_factories_config) might come in handy.

Also, to increase the available memory for your J2EE server, look for the startup scripts for the server. When the VM is created (using the 'java' command, check the following arguements to the executable -Xms and -Xmx.
ms - denotes starting heap size and mx- denotes max heap size that the VM can grow to. If you have a lot of ohysical memory available say a 512 MB RAM. try java -Xms 256 -Xmx 256.

Regards
pradeeP