Access session bean in ViewObjectImpl

Hi all,
Is it possible to access session bean (Managed bean) in ViewObjectImpl class?
The use case is that I hope to add a whereclause for the VO in a bounded task flow before a specific page fragment using that VO is loaded. Thanks for any advice~~
Andrew

Thanks for the reply.
So the only way to set a VO where clause before a page fragment is loaded is by :
public boolean refreshRegion(RegionContext regionContext) {
int refreshFlag = regionContext.getRefreshFlag();
if ((refreshFlag == 1 && !this.isPostback())) {
// set the VO where clause here...
Any declarative way like "invokeaction" in the binding of the page fragment to set the where clause? Thanks a lot~

Similar Messages

JNDI Naming Problem accessing Session Bean from Message Driven Bean

Hi,
     I am facing a very strange problem in JNDI look up accessing a Session Bean from a Message Driven Bean. I have a session fa�ade bean(Remote Bean) which is being called from Struts Action class getting the home reference from the ServiceLocator (I have implemented ServiceLocator pattern to obtain JNDI reference for all EJBs). When I am calling the session fa�ade EJB from the Struts Action class everything is working fine.
     But when I am trying to call the same EJB from my Message Driven Bean, I am getting a JNDI exception (NameNotFoundException - No Object bound to name �java:comp/env/ejb/EJBJNDIName�). I am trying to get the remote reference from the same ServiceLocator which is successfully providing me a reference while calling from the struts action class. But the same ServiceLocator is not able to provide me a reference while calling from the Message Driven Bean. If I use the JNDI name directly like �EJBJNDIName� in the lookup it is working fine. The lookup for the name is working fine and I am able to call the Session Fa�ade bean with that reference.
     I am really not sure what exactly the problem is. If I have any problem in the ServiceLocator, it should have given me the same error while calling from Struts Action class. But it is working fine with the full name �java:comp/env/ejb/EJBJNDIName� calling from the struts action class. I am not sure whether Message Driven Bean has something to do with it. Why I am not able to get a reference of the EJB with the full name? Please Help.
Thanks
Amit

Hi Bhagya,
Thanks for your response. I think from EJB container we can call Local EJBs with the full JNDI name. The session facade bean which is being called is a remote bean. From the session facade bean I am calling a local stateless session bean for database access. I am getting the reference of the local EJB from my session facade bean with full JNDI name "java:comp/env/ejb/EJBJNDIName". It is working fine with out any problem. My servicelocator is able to provide me the reference of the local EJB from the session facade remote bean with Full JNDI name. I am only having this problem calling from the MDB. I am really not sure whether what is causing it?
Thanks
Amit

Java.lang.ClassCastException in jsp trying to access session bean

Ok I'm totally stuck on this. I've been able to deploy my session bean facade to a bunch of entities bean with no problem. Now I'm trying to access the bean from a JSP. I can do a lookup ok, I can even do a PortableRemoteObject.narrow() ok, but when I try to actually cast the object I get an error. I can't understand why narrow works if the object is not of the correct type, when I do reflection I can verify that the object implements the interface I am trying to cast to. But when I do an instanceof the object from narrow is not the right type. I'm totally confused by this.
Here's my jsp,
<%@taglib uri="/com/sct/socrates/web/jsp/tld/UserAdmin.tld" prefix="UserAdmin" %>
<%@ page import="java.sql.*" %>
<%@ page import="javax.naming.*" %>
<%@ page import="com.sct.socrates.useradmin.model.UserAdminHome" %>
<%@page import="javax.rmi.PortableRemoteObject"%>
<html>
<body>
<pre>
<%
try {
InitialContext context = new InitialContext();
Object object1 = context.lookup("com.sct.socrates.useradmin.model.UserAdminHome");
out.println(object1.getClass().getName());
Object object2 = PortableRemoteObject.narrow(object1, UserAdminHome.class);
out.println(object2.getClass().getName());
if (object2 instanceof UserAdminHome) out.println("is instance");
Class[] list = object2.getClass().getInterfaces();
for(int i=0;i<list.length;i++)
out.println(list.getName());
UserAdminHome home = (UserAdminHome) object2;
} catch (Exception e){
e.printStackTrace();
%>
</pre>
</body>
</html>
Here's the output from the JSP,
com.sct.socrates.useradmin.model._UserAdminHome_Stub
com.sct.socrates.useradmin.model._UserAdminHome_Stub
com.sct.socrates.useradmin.model.UserAdminHome
Here's the server output,
FINE: for host 127.0.0.1 trying to GET /socrates/jsp/guest/test.jsp, ntrans-j2ee reports: mapped uri "/jsp/guest/test.jsp" in context "/socrates" to resource
FINE: context = StandardEngine[null].StandardHost[server1].StandardContext[socrates]
FINE: contextPath = /socrates
FINE: wrapper = StandardEngine[null].StandardHost[server1].StandardContext[socrates].StandardWrapper[jsp]
FINE: servletPath = /jsp/guest/test.jsp
FINE: pathInfo = null
FINE: SingleSignOn[server1]: Process request for '/socrates/jsp/guest/test.jsp'
FINE: SingleSignOn[server1]: Checking for SSO cookie
FINE: SingleSignOn[server1]: SSO cookie is not present
FINE: Authenticator[socrates]: Security checking request GET /socrates/jsp/guest/test.jsp
FINE: Authenticator[socrates]: Checking constraint 'SecurityConstraint[community]' against GET /jsp/guest/test.jsp --> false
FINE: Authenticator[socrates]: Checking constraint 'SecurityConstraint[user]' against GET /jsp/guest/test.jsp --> false
FINE: Authenticator[socrates]: Checking constraint 'SecurityConstraint[community]' against GET /jsp/guest/test.jsp --> false
FINE: Authenticator[socrates]: Checking constraint 'SecurityConstraint[moderator]' against GET /jsp/guest/test.jsp --> false
FINE: Authenticator[socrates]: Checking constraint 'SecurityConstraint[admin]' against GET /jsp/guest/test.jsp --> false
FINE: Authenticator[socrates]: No applicable constraint located
FINE: Authenticator[socrates]: Not subject to any constraint
FINE: JspEngine --> /jsp/guest/test.jsp
FINE: ServletPath: /jsp/guest/test.jsp
FINE: PathInfo: null
FINE: RealPath: E:\dev\app_server\sun\appserv\domains\domain1\server1\applications\j2ee-apps\socrates_3\socrates_war\jsp\guest\test.jsp
FINE: RequestURI: /socrates/jsp/guest/test.jsp
FINE: QueryString: null
FINE: ++++ Entered SecClientRequestInterceptor::send_request()
FINE: Security context is null (nothing to add to service context)
FINE: No SAS context element found in service context list
FINE: ++++ Entered SecClientRequestInterceptor::receive_reply
FINE: No SAS context element found in service context list
FINE: Status to be set : 0
FINE: Invoked receivedReply()
FINE: ++++ Entered SecClientRequestInterceptor::send_request()
FINE: Security context is null (nothing to add to service context)
FINE: No SAS context element found in service context list
FINE: ++++ Entered SecClientRequestInterceptor::receive_reply
FINE: No SAS context element found in service context list
FINE: Status to be set : 0
FINE: Invoked receivedReply()
FINE: service-j2ee: name = "com.sct.socrates.useradmin.model._UserAdminHome_Stub", codebase = ""
FINER: service-j2ee: (thread context class loader: WebappClassLoader
available:
delegate: false
repositories:
/WEB-INF/classes/
required:
----------> Parent Classloader:
EJB CL:
[com.iplanet.ias.loader.EJBClassLoader$URLEntry@e1df6e, com.iplanet.ias.loader.EJBClassLoader$URLEntry@13b9fb]
FINER: service-j2ee: class "com.sct.socrates.useradmin.model._UserAdminHome_Stub" found via codebase, defined by EJB CL:
[com.iplanet.ias.loader.EJBClassLoader$URLEntry@e1df6e, com.iplanet.ias.loader.EJBClassLoader$URLEntry@13b9fb]
FINE: ++++ Entered SecClientRequestInterceptor::send_request()
FINE: Security context is null (nothing to add to service context)
FINE: No SAS context element found in service context list
FINE: ++++ Entered SecClientRequestInterceptor::receive_reply
FINE: No SAS context element found in service context list
FINE: Status to be set : 0
FINE: Invoked receivedReply()
FINE: service-j2ee: name = "com.sct.socrates.useradmin.model._UserAdminHome_Stub", codebase = ""
FINER: service-j2ee: (thread context class loader: WebappClassLoader
available:
delegate: false
repositories:
/WEB-INF/classes/
required:
----------> Parent Classloader:
EJB CL:
[com.iplanet.ias.loader.EJBClassLoader$URLEntry@e1df6e, com.iplanet.ias.loader.EJBClassLoader$URLEntry@13b9fb]
FINER: service-j2ee: class "com.sct.socrates.useradmin.model._UserAdminHome_Stub" found via codebase, defined by EJB CL:
[com.iplanet.ias.loader.EJBClassLoader$URLEntry@e1df6e, com.iplanet.ias.loader.EJBClassLoader$URLEntry@13b9fb]
WARNING: CORE3283: stderr: java.lang.ClassCastException: com.sct.socrates.useradmin.model._UserAdminHome_Stub
WARNING: CORE3283: stderr: at jasper.jsp._guest._test_jsp._jspService(_test_jsp.java:89)
WARNING: CORE3283: stderr: at org.apache.jasper.runtime.HttpJspBase.service(Unknown Source)
WARNING: CORE3283: stderr: at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
WARNING: CORE3283: stderr: at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(Unknown Source)
WARNING: CORE3283: stderr: at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(Unknown Source)
WARNING: CORE3283: stderr: at com.iplanet.ias.web.jsp.JspServlet.service(Unknown Source)
WARNING: CORE3283: stderr: at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardWrapperValve.invokeServletService(Unknown Source)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardWrapperValve.access$000(Unknown Source)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardWrapperValve$1.run(Unknown Source)
WARNING: CORE3283: stderr: at java.security.AccessController.doPrivileged(Native Method)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source)
WARNING: CORE3283: stderr: at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
WARNING: CORE3283: stderr: at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(Unknown Source)
WARNING: CORE3283: stderr: at com.iplanet.ias.web.WebContainer.service(Unknown Source)

Please configure the classloader to delegate to the parent loader by specifying the following in WEB-INF/sun-web.xml (the Sun ONE Application Server specific deployment descriptor for web applications)
<class-loader delegate="true"/>
More information on this can be found at
http://docs.sun.com/source/816-7150-10/dwdeploy.html#48102
Thanks,
Arvind

Accessing the same stateful session bean from multiple clients in a clustered environment

I am trying to access the same stateful session bean from multiple
          clients. I also want this bean to have failover support so we want to
          deploy it in a cluster. The following description is how we have tried
          to solve this problem, but it does not seem to be working. Any
          insight would be greatly appreciated!
          I have set up a cluster of three servers. I deployed a stateful
          session bean with in memory replication across the cluster. A client
          obtains a reference to an instance of one of these beans to handle a
          request. Subsequent requests will have to use the same bean and could
          come from various clients. So after using the bean the first client
          stores the handle to the bean (actually the replica aware stub) to be
          used by other clients to be able to obtain the bean. When another
          client retrieves the handle gets the replica aware stub and makes a
          call to the bean the request seems to unpredictably go to any of the
          three servers rather than the primary server hosting that bean. If the
          call goes to the primary server everything seems to work fine the
          session data is available and it gets backed up on the secondary
          server. If it happens to go to the secondary server a bean that has
          the correct session data services the request but gives the error
          <Failed to update the secondary copy of a stateful session bean from
          home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          to the primary server will not reflect changes made on the secondary
          and vice versa. If the request happens to go to the third server that
          is not hosting an instance of that bean then the client receives an
          error that the bean was not available. From my understanding I thought
          the replica aware stub would know which server is the primary host for
          that bean and send the request there.
          Thanks in advance,
          Justin


          If 'allow-concurrent-call' does exactly what you need, then you don't have a problem,
          do you?
          Except of course if you switch ejb containers. Oh well.
          Mike
          "FBenvadi" <[email protected]> wrote:
          >I've got the same problem.
          >I understand from you that concurrent access to a stateful session bean
          >is
          >not allowed but there is a
          >token is weblogic-ejb-jar.xml that is called 'allow-concurrent-call'
          >that
          >does exactly what I need.
          >What you mean 'you'll get a surprise when you go to production' ?
          >I need to understand becouse I can still change the design.
          >Thanks Francesco
          >[email protected]
          >
          >"Mike Reiche" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >> Get the fix immediately from BEA and test it. It would be a shame to
          >wait
          >until
          >> December only to get a fix - that doesn't work.
          >>
          >> As for stateful session bean use - just remember that concurrent access
          >to
          >a stateful
          >> session bean is not allowed. Things will work fine until you go to
          >production
          >> and encounter some real load - then you will get a surprise.
          >>
          >> Mike
          >>
          >> [email protected] (Justin Meyer) wrote:
          >> >I just heard back from WebLogic Tech Support and they have confirmed
          >> >that this is a bug. Here is their reply:
          >> >
          >> >There is some problem in failover of stateful session beans when its
          >> >run from a java client.However, it is fixed now.
          >> >
          >> >The fix will be in SP2 which will be out by december.
          >> >
          >> >
          >> >Mike,
          >> >Thanks for your reply. I do infact believe we are correctly using
          >a
          >> >stateful session bean however it may have been misleading from my
          >> >description of the problem. We are not accessing the bean
          >> >concurrently from 2 different clients. The second client will only
          >> >come into play if the first client fails. In this case we want to
          >be
          >> >able to reacquire the handle to our stateful session bean and call
          >it
          >> >from the secondary client.
          >> >
          >> >
          >> >Justin
          >> >
          >> >"Mike Reiche" <[email protected]> wrote in message
          >news:<[email protected]>...
          >> >> You should be using an entity bean, not a stateful session bean
          >for
          >> >this application.
          >> >>
          >> >> A stateful session bean is intended to be keep state (stateful)
          >for
          >> >the duration
          >> >> of a client's session (session).
          >> >>
          >> >> It is not meant to be shared by different clients - in fact, if
          >you
          >> >attempt to
          >> >> access the same stateful session bean concurrently - it will throw
          >> >an exception.
          >> >>
          >> >> We did your little trick (storing/retrieving handle) with a stateful
          >> >session bean
          >> >> on WLS 5.1 - and it did work properly - not as you describe. Our
          >sfsb's
          >> >were not
          >> >> replicated as yours are.
          >> >>
          >> >> Mike
          >> >>
          >> >> [email protected] (Justin Meyer) wrote:
          >> >> >I am trying to access the same stateful session bean from multiple
          >> >> >clients. I also want this bean to have failover support so we want
          >> >to
          >> >> >deploy it in a cluster. The following description is how we have
          >tried
          >> >> >to solve this problem, but it does not seem to be working. Any
          >> >> >insight would be greatly appreciated!
          >> >> >
          >> >> >I have set up a cluster of three servers. I deployed a stateful
          >> >> >session bean with in memory replication across the cluster. A client
          >> >> >obtains a reference to an instance of one of these beans to handle
          >> >a
          >> >> >request. Subsequent requests will have to use the same bean and
          >could
          >> >> >come from various clients. So after using the bean the first client
          >> >> >stores the handle to the bean (actually the replica aware stub)
          >to
          >> >be
          >> >> >used by other clients to be able to obtain the bean. When another
          >> >> >client retrieves the handle gets the replica aware stub and makes
          >> >a
          >> >> >call to the bean the request seems to unpredictably go to any of
          >the
          >> >> >three servers rather than the primary server hosting that bean.
          >If
          >> >the
          >> >> >call goes to the primary server everything seems to work fine the
          >> >> >session data is available and it gets backed up on the secondary
          >> >> >server. If it happens to go to the secondary server a bean that
          >has
          >> >> >the correct session data services the request but gives the error
          >> >> ><Failed to update the secondary copy of a stateful session bean
          >from
          >> >> >home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          >> >> >to the primary server will not reflect changes made on the secondary
          >> >> >and vice versa. If the request happens to go to the third server
          >that
          >> >> >is not hosting an instance of that bean then the client receives
          >an
          >> >> >error that the bean was not available. From my understanding I
          >thought
          >> >> >the replica aware stub would know which server is the primary host
          >> >for
          >> >> >that bean and send the request there.
          >> >> >
          >> >> >Thanks in advance,
          >> >> >Justin
          >>
          >
          >

Problems accessing fields in a CMP entity bean from a session bean

Hello everybody,
I'm getting the next problem: when I try to access a field in a CMP entity bean that I have instantiated from a session bean (trhoug entitybean.getNameOfField), I get the error "the entity bean does not exist in the database".
This entity bean is accessing a table in an external database (not the DB of the WAS), but I know that it's getting the correct data from the table, since I check the entitybean.size() and the entitybean.findByPrimaryKey(), and I get the right information. For some reason, the only thing that it doesn't work in the entity bean are the getter/setter methods (I created them automatically after having created the entity fields).
I access the entity bean through its local interface...
I know it's really difficult to give an answer with so few details, but... does anybody think I forgot something important to configure??
Thank very much in advance!!
Isidro

getter and setter methods for cmp-fields are abstract.
getter and setter methods for cmr-fields are abstract.
"John Lee" <[email protected]> wrote:
>
Hi:
Which method in a CMP Entity bean should be abstract? just only SetXXX
and
GetXXX?
Thanks!
John Lee

How to get access via RMI from a session bean to a remote session bean?

I have 2 J2EE applications in two different Sun Application Servers (8.0 PE). I would like to get access from one Session Bean "SB1" into Application A to Session Bean "BrickFacade" within Application B.
My Java Code from "SB1":
         Context ic = new InitialContext();
         Object o = ic.lookup("java:comp/env/ejb/BrickFacade");
         BrickFacadeHome brickFacadeHome2 = (BrickFacadeHome) PortableRemoteObject.narrow(o, BrickFacadeHome.class);
         brickFacade = brickFacadeHome2.create();
         Collection col = brickFacade.doSomething();
         ...I configured the remote App.server in sun-ejb-jar.xml. I found the syntax within documentation (http://docs.sun.com/source/817-6087/dgjndi.html#wp24622) but I'm not sure if I this is the right usage.
     <ejb-ref>
        <ejb-ref-name>ejb/BrickFacade</ejb-ref-name>
        <jndi-name>corbaname:iiop://161.90.176.213:3700#webclient/BrickFacade</jndi-name>
      </ejb-ref>The context lookup throws the exception:
"IOP00110603: (BAD_PARAM) Bad host address in -ORBInitDef"
and
Invalid URL or IOR: corbaloc:iiop://161.90.176.213:3700
javax.naming.ConfigurationException: Invalid URL or IOR: corbaloc:iiop://161.90.176.213:3700 [Root exception is org.omg.CORBA.BAD_PARAM:   vmcid: SUN minor code: 603 completed: No]
Could anyone help me? Many thanks!
Stacktrace:
"IOP00110603: (BAD_PARAM) Bad host address in -ORBInitDef"
org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 603 completed: No
     at com.sun.corba.ee.impl.logging.NamingSystemException.insBadAddress(NamingSystemException.java:148)
     at com.sun.corba.ee.impl.logging.NamingSystemException.insBadAddress(NamingSystemException.java:166)
     at com.sun.corba.ee.impl.naming.namingutil.CorbalocURL.badAddress(CorbalocURL.java:104)
     at com.sun.corba.ee.impl.naming.namingutil.CorbalocURL.handleColon(CorbalocURL.java:140)
     at com.sun.corba.ee.impl.naming.namingutil.CorbalocURL.handleIIOPColon(CorbalocURL.java:115)
     at com.sun.corba.ee.impl.naming.namingutil.CorbalocURL.<init>(CorbalocURL.java:67)
     at com.sun.corba.ee.impl.naming.namingutil.INSURLHandler.parseURL(INSURLHandler.java:41)
     at com.sun.corba.ee.impl.resolver.INSURLOperationImpl.operate(INSURLOperationImpl.java:103)
     at com.sun.corba.ee.impl.orb.ORBImpl.string_to_object(ORBImpl.java:774)
     at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:338)
     at com.sun.jndi.cosnaming.CNCtx.initUsingCorbanameUrl(CNCtx.java:321)
     at com.sun.jndi.cosnaming.CNCtx.initUsingUrl(CNCtx.java:247)
     at com.sun.jndi.cosnaming.CNCtx.createUsingURL(CNCtx.java:85)
     at com.sun.jndi.url.iiop.iiopURLContextFactory.getUsingURLIgnoreRest(iiopURLContextFactory.java:56)
     at com.sun.jndi.url.iiop.iiopURLContext.getRootURLContext(iiopURLContext.java:44)
     at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:182)
     at javax.naming.InitialContext.lookup(InitialContext.java:347)
     at com.sun.enterprise.naming.NamingManagerImpl.lookup(NamingManagerImpl.java:702)
     at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:108)
     at javax.naming.InitialContext.lookup(InitialContext.java:347)
     at de.emilberlinerstudios.va.ejb.testrh.sb.TestRemoteEjbBean.getBrickFacade(TestRemoteEjbBean.java:108)
     at de.emilberlinerstudios.va.ejb.testrh.sb.TestRemoteEjbBean.startTest(TestRemoteEjbBean.java:79)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:324)
     at com.sun.enterprise.security.SecurityUtil$2.run(SecurityUtil.java:146)
     at java.security.AccessController.doPrivileged(Native Method)
     at com.sun.enterprise.security.application.EJBSecurityManager.doAsPrivileged(EJBSecurityManager.java:930)
     at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:151)
     at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:128)
     at $Proxy7.startTest(Unknown Source)
     at de.emilberlinerstudios.va.ejb.testrh.sb._TestRemoteEjb_Stub.startTest(Unknown Source)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:324)
     at com.sun.forte4j.j2ee.ejbtest.webtest.InvocableMethod$MethodIM.invoke(InvocableMethod.java:231)
     at com.sun.forte4j.j2ee.ejbtest.webtest.EjbInvoker.getInvocationResults(EjbInvoker.java:96)
     at com.sun.forte4j.j2ee.ejbtest.webtest.DispatchHelper.getForward(DispatchHelper.java:189)
     at org.apache.jsp.dispatch_jsp._jspService(dispatch_jsp.java:75)
     at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:102)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:861)
     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:282)
     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:263)
     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:210)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:861)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:324)
     at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:246)
     at java.security.AccessController.doPrivileged(Native Method)
     at javax.security.auth.Subject.doAsPrivileged(Subject.java:500)
     at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:268)
     at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:236)
     at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
     at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:145)
     at java.security.AccessController.doPrivileged(Native Method)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:141)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
     at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:214)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:168)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:144)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:133)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:539)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at com.sun.enterprise.webservice.EjbWebServiceValve.invoke(EjbWebServiceValve.java:134)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at com.sun.enterprise.security.web.SingleSignOn.invoke(SingleSignOn.java:272)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at com.sun.enterprise.web.VirtualServerValve.invoke(VirtualServerValve.java:209)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:114)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109)
     at com.sun.enterprise.web.VirtualServerMappingValve.invoke(VirtualServerMappingValve.java:166)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:936)
     at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:165)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:683)
     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:604)
     at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:542)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:647)
     at java.lang.Thread.run(Thread.java:534)
|#]
[#|2006-10-02T13:52:55.390+0200|INFO|sun-appserver-pe8.0.0_01|javax.enterprise.system.stream.out|_ThreadID=11;|2006-10-02 13:52:55 [8080-Processor4] INFO .va.ejb.testrh.sb.TestRemoteEjbBean - RemoteException when getting BrickFacade. Message:Invalid URL or IOR: corbaloc:iiop://161.90.176.213:3700
javax.naming.ConfigurationException: Invalid URL or IOR: corbaloc:iiop://161.90.176.213:3700 [Root exception is org.omg.CORBA.BAD_PARAM:   vmcid: SUN minor code: 603 completed: No]
     at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:367)
     at com.sun.jndi.cosnaming.CNCtx.initUsingCorbanameUrl(CNCtx.java:321)
     at com.sun.jndi.cosnaming.CNCtx.initUsingUrl(CNCtx.java:247)
     at com.sun.jndi.cosnaming.CNCtx.createUsingURL(CNCtx.java:85)
     at com.sun.jndi.url.iiop.iiopURLContextFactory.getUsingURLIgnoreRest(iiopURLContextFactory.java:56)
     at com.sun.jndi.url.iiop.iiopURLContext.getRootURLContext(iiopURLContext.java:44)
     at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:182)
     at javax.naming.InitialContext.lookup(InitialContext.java:347)
     at com.sun.enterprise.naming.NamingManagerImpl.lookup(NamingManagerImpl.java:702)
     at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:108)
     at javax.naming.InitialContext.lookup(InitialContext.java:347)
     at de.emilberlinerstudios.va.ejb.testrh.sb.TestRemoteEjbBean.getBrickFacade(TestRemoteEjbBean.java:108)
     at de.emilberlinerstudios.va.ejb.testrh.sb.TestRemoteEjbBean.startTest(TestRemoteEjbBean.java:79)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:324)
     at com.sun.enterprise.security.SecurityUtil$2.run(SecurityUtil.java:146)
     at java.security.AccessController.doPrivileged(Native Method)
     at com.sun.enterprise.security.application.EJBSecurityManager.doAsPrivileged(EJBSecurityManager.java:930)
     at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:151)
     at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:128)
     at $Proxy7.startTest(Unknown Source)
     at de.emilberlinerstudios.va.ejb.testrh.sb._TestRemoteEjb_Stub.startTest(Unknown Source)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:324)
     at com.sun.forte4j.j2ee.ejbtest.webtest.InvocableMethod$MethodIM.invoke(InvocableMethod.java:231)
     at com.sun.forte4j.j2ee.ejbtest.webtest.EjbInvoker.getInvocationResults(EjbInvoker.java:96)
     at com.sun.forte4j.j2ee.ejbtest.webtest.DispatchHelper.getForward(DispatchHelper.java:189)
     at org.apache.jsp.dispatch_jsp._jspService(dispatch_jsp.java:75)
     at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:102)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:861)
     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:282)
     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:263)
     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:210)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:861)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:324)
     at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:246)
     at java.security.AccessController.doPrivileged(Native Method)
     at javax.security.auth.Subject.doAsPrivileged(Subject.java:500)
     at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:268)
     at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:236)
     at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
     at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:145)
     at java.security.AccessController.doPrivileged(Native Method)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:141)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
     at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:214)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:168)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:144)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:133)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:539)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at com.sun.enterprise.webservice.EjbWebServiceValve.invoke(EjbWebServiceValve.java:134)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at com.sun.enterprise.security.web.SingleSignOn.invoke(SingleSignOn.java:272)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at com.sun.enterprise.web.VirtualServerValve.invoke(VirtualServerValve.java:209)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:114)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:109)
     at com.sun.enterprise.web.VirtualServerMappingValve.invoke(VirtualServerMappingValve.java:166)
     at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:107)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:522)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:936)
     at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:165)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:683)
     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:604)
     at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:542)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:647)
     at java.lang.Thread.run(Thread.java:534)
Caused by: org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 603 completed: No
     at com.sun.corba.ee.impl.logging.NamingSystemException.insBadAddress(NamingSystemException.java:148)
     at com.sun.corba.ee.impl.logging.NamingSystemException.insBadAddress(NamingSystemException.java:166)
     at com.sun.corba.ee.impl.naming.namingutil.CorbalocURL.badAddress(CorbalocURL.java:104)
     at com.sun.corba.ee.impl.naming.namingutil.CorbalocURL.handleColon(CorbalocURL.java:140)
     at com.sun.corba.ee.impl.naming.namingutil.CorbalocURL.handleIIOPColon(CorbalocURL.java:115)
     at com.sun.corba.ee.impl.naming.namingutil.CorbalocURL.<init>(CorbalocURL.java:67)
     at com.sun.corba.ee.impl.naming.namingutil.INSURLHandler.parseURL(INSURLHandler.java:41)
     at com.sun.corba.ee.impl.resolver.INSURLOperationImpl.operate(INSURLOperationImpl.java:103)
     at com.sun.corba.ee.impl.orb.ORBImpl.string_to_object(ORBImpl.java:774)
     at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.j|#]

Problem solved:
configuration in jndi-name was wrong:
<jndi-name>corbaname:iiop:161.90.176.213:3700#ejb/BrickFacade</jndi-name>

NON-transactional session bean access entity bean

We are currently profiling our product using Borland OptmizeIt tool, and we
found some interesting issues. Due to our design, we have many session beans which
are non transactional, and these session beans will access entity beans to do
the reading operations, such as getWeight, getRate, since it's read only, there
is no need to do transaction commit stuff which really takes time, this could
be seen through the profile. I know weblogic support readonly entity bean, but
it seems that it only has benefit on ejbLoad call, my test program shows that
weblogic still creates local transaction even I specified it as transaction not
supported, and Transaction.commit() will always be called in postInvoke(), from
the profile, we got that for a single method call, such as getRate(), 80% time
spent on postInvoke(), any suggestion on this? BTW, most of our entity beans are
using Exclusive lock, that's the reason that we use non-transactional session
bean to avoid dead lock problem.
Thanks

Slava,
Thanks for the link, actually I read it before, and following is what I extracted
it from the doc:
<weblogic-doc>
Do not set db-is-shared to "false" if you set the entity bean's concurrency
strategy to the "Database" option. If you do, WebLogic Server will ignore the
db-is-shared setting.
</weblogic-doc>
Thanks
"Slava Imeshev" <[email protected]> wrote:
Hi Jinsong,
You may want to read this to get more detailed explanation
on db-is-shared (cache-between-transactions for 7.0):
http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1127563
Let me know if you have any questions.
Regards,
Slava Imeshev
"Jinsong HU" <[email protected]> wrote in message
news:[email protected]...
Thanks.
But it's still not clear to me in db-is-shared setting, if I specifiedentity
lock as database lock, I assumed db-is-shared is useless, because foreach
new
transaction, entity bean will reload data anyway. Correct me if I amwrong.
Jinsong
"Slava Imeshev" <[email protected]> wrote:
Jinsong,
See my answers inline.
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
Hi Slava,
Thanks for your reply, actually, I agree with you, we need to
review
our db
schema and seperate business logic to avoid db lock. I can not say,guys,
we need
to change this and that, since it's a big application and developedsince
EJB1.0
spec, I think they are afraid to do such a big change.Total rewrite is the worst thing that can happen to an app. The
better aproach would be identifying the most critical piece and
make a surgery on it.
Following are questions in my mind:
(1) I think there should be many companies using weblogic serverto
develop
large enterprise applications, I am just wondering what's the maintransaction/lock
mechanism that is used? Transional session / database lock,
db-is-shared
entity
I can't say for the whole community, as for my experience the standard
usage patthern is session fasades calling Entity EJBs while having
Required TX attribute plus plain transacted JDBC calls for bulk
reads or inserts.
is the dominant one? It seems that if you speficy database lock,
the
db-is-shared
should be true, right?Basically it's not true. One will need db-is-shared only if thereare
changes
to the database done from outside of the app server.
(2) For RO bean, if I specify read-idle-timeout to 0, it shouldonly
load
once at the first use time, right?I assume read-timeout-seconds was meant. That's right, but if
an application constantly reads new RO data, RO beans will be
constantly dropped from cache and new ones will be loaded.
You may want to looks at server console to see if there's a lot
of passivation for RO beans.
(3) For clustering part, have anyone use it in real enterpriseapplication?
My concern, since database lock is the only way to choose, how aboutthe
affect
of ejbLoad to performance, since most transactions are short live,if high
volume
transactions are in processing, I am just scared to death about
the
ejbLoad overhead.
ejbLoad is a part of bean's lifecycle, how would you be scared ofit?
If ejbLoads take too much time, it could be a good idea to profile
used SQLs. Right index optimization can make huge difference.
Also you may want cosider using CMP beans to let weblogic
take care about load optimization.
(4) If using Optimization lock, all the ejbStore need to do
version
check
or timestamp check, right? How about this overhead?As for optimistic concurrency, it performs quite well as you can
use lighter isolation levels.
HTH,
Slava Imeshev
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
We are using Exclusive Lock for entity bean, because of we do
not
want
to
load
data in each new transaction. If we use Database lock, that means
we
dedicate
data access calls to database, if database deadlock happens,
it's
hard
to
detect,
while using Exclusive lock, we could detect this dead lock in
container
level.
The problem is, using Exclusive concurrency mode you serialize
access to data represented by the bean. This aproach has negative
effect on ablity of application to process concurrent requests.As
a
result the app may have performance problems under load.
Actually, at the beginnning, we did use database lock and usingtransactional
The fact that you had database deadlocking issues tells that
application logic / database schema may need some review.
Normally to avoid deadlocking it's good to group database
operations mixing in updattes and inserts into one place so
that db locking sequence is not spreaded in time. Moving to
forced serialized data access just hides design/implementation
problems.
session bean, but the database dead lock and frequent ejbLoad
really
kill
us,
so we decided to move to use Exclusive lock and to avoid dead
lock,
we
change
some session bean to non-transactional.Making session beans non-transactions makes container
creating short-living transactions for each call to entity bean
methods. It's a costly process and it puts additional load to
both container and database.
We could use ReadOnly lock for some entity beans, but since weblogicserver will
always create local transaction for entity bean, and we found
transaction
commit
is expensive, I am arguing why do we need create container leveltransaction for
read only bean.First, read-only beans still need to load data. Also, you may seeRO
beans
contanly loading data if db-is-shared set to true. Other reason
can
be
that
RO semantics is not applicable the data presented by RO bean (forinstance,
you have a reporting engine that constantly produces "RO" data,
while
application-consumer of that data retrieves only new data and neverasks
for "old" data). RO beans are good when there is a relatively stable
data
accessed repeatedly for read only access.
You may want to tell us more about your app, we may be of help.
Regards,
Slava Imeshev
I will post the performance data, let's see how costful
transaction.commit
is.
"Cameron Purdy" <[email protected]> wrote:
We are currently profiling our product using Borland
OptmizeIt
tool,
and we
found some interesting issues. Due to our design, we have
many
session
beans which
are non transactional, and these session beans will access
entity
beans
to
do
the reading operations, such as getWeight, getRate, since
it's
read
only,
there
is no need to do transaction commit stuff which really takes
time,
this
could
be seen through the profile. I know weblogic support readonly
entity
bean,
but
it seems that it only has benefit on ejbLoad call, my test
program
shows
that
weblogic still creates local transaction even I specified
it
as
transaction not
supported, and Transaction.commit() will always be called
in
postInvoke(),
from
the profile, we got that for a single method call, such as
getRate(),
80%
time
spent on postInvoke(), any suggestion on this? BTW, most of
our
entity
beans are
using Exclusive lock, that's the reason that we use
non-transactional
session
bean to avoid dead lock problem.I am worried that you have made some decisions based on an improper
understand of what WebLogic is doing.
First, you say "non transactional", but from your description
you
should
have those marked as tx REQUIRED to avoid multiple transactions
(since
non-transactional just means that the database operation becomesits
own
little transaction).
Second, you say you are using exclusive lock, which you shouldonly
use
if
you are absolutely sure that you need it, (and note that it
does
not
work in
a cluster).
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com/coherence.jsp
Tangosol Coherence: Clustered Replicated Cache for Weblogic
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
>

Accessing Managed Session Bean in Servlet Filter

I wrote a Servlet Filter to handle user authentication. Now I'm trying to access my Managed Session Bean in the filter in order to save the current user. Unfortunately the Session Bean is created after the Filter executes for the first time.
I'm trying to access the Session Bean in this way:
(SessionBean) FacesContext.getCurrentInstance().getExternalContext().getSessionMap().get("sessionBean");
In this case getExternalContext() is equals null.
Is there any way to create the Session bean before the filter executes or any other ideas how to handle this?
I already searched around the internet but couldnt figure out something.
Thanks guys,
Paul

Ok, fixed it like this. Works perfect. JSF finds and uses the handmade Session Bean as well.
if(request.getSession().getAttribute(BeanNames.SESSION_SCOPE_BEAN) == null) {
SessionBean sessionBean = new SessionBean();
request.getSession().setAttribute(BeanNames.SESSION_SCOPE_BEAN, sessionBean);
}Thanks,
Paul

Database access from session bean

Hello,
I have a stateless session bean which performs some complex
calculations, and also does some database access.
For the database access the bean class has a datasource as
follows:
public class TestBean implements SessionBean {
private DataSource ds_;
public void ejbCreate() {
     getDataSources();
private void getDataSources() {
     try {
     Context ictx = new InitialContext();
     ds_ = (DataSource)ictx.lookup("java:comp/env/jdbc/TestDB");
     } catch (Exception e) {
     e.printStackTrace();
     throw new EJBException(e);
Now this class has a method (which is also in the remote interface)
calculateSomething(). This method constructs a number of other
objects that do the actual calculation, and one of these objects
does the actual database access. How would another object be able to
use the datasource that was constructed in the bean class?
I could pass the datasource reference to that object, but that would
break my encapsulation. This is because that object does not get
created directly by the bean object, but rather the way the objects
interact is something like A -> B -> C, where A is the TestBean, and
C is the object that does the DB access. If I passed the datasource,
I would need to make B aware of the datasource, which doesn't
seem good design, because B doesn't do any database access.
Alternatively I could do the lookup in class C, but that would
degrade the performance, as an object C gets created and destroyed
every time the calculateSomething() method is called.
A third option I have thought of, is to add a public method to the
bean that returns a connection. Whenever another object gets
created, a reference to the bean object will be passed along. Then,
if another object needs to do database access, it will call back
the bean to get a connection. This seems just as bad (if not worse)
than the first option.
Does anyone have an elegant solution for this situation? What is
the best practice of handling datasources when a bean class doesn't
do the database access itself? In all the examples I've seen so far,
all the functionality was in the session bean class, but again that
doesn't seem good OO design, and would result in a single huge class.
regards,
Kostas

Thanks again to both for the replies. Here are my responses:
Yi Lin: Yes, I know that an entity bean would solve this problem, however it has been decided not to use entity beans so this is not my call (I think the reason entity beans are not allowed in this project is that they are considered risky: there are other applications that access the same database, so if the container caches entity bean data as you describe, then the users might get inconsistent results).
Gerard: Actually object B is the one that has the business logic and C is a peer object that only does database access and no calculaitons. For example B can be Customer, and C CustomerDB. This is why object B does not have any knowledge of datasources or connections. So my design does not appear to be that bad!
As far as the factory you propose is concerned, I cannot understand how this would solve my problem. In order to solve this situation the factory would need to be persistent, i.e. get created by the ejbCreate() method, and destroyed whenever the container decides to destroy the bean. There would be no point in object C creating the factory, as I would have the overhead of doing the JNDI lookup every time I create a C.
So the question remains the same: how would I pass a reference to the factory from A to C without making B aware of it?

ADF BC how to access session backing bean value in servlet

Hi everyone,
How do I access session backing bean value in a servlet?

Frank, thanks for your reply.
I'm not sure how I can incorporate this example into my situation. Let me explain more detail about my problem.
"servlet" in my post here actually means a custom servlet I wrote for rendering an image that is stored in db as ordimage. In this servlet, I get hold of my appmodule by using Configuation.createRootApplicationModule(). By doing so (If I'm not wrong) a new database session/connection is created. What I'm going to achieve is set application context for this new session/connection in db with the data stored in a session backing bean in the view layer.
I can pass the required data to the servlet thru url parameter, but I don't want to do it this way for the reason that the data may contains sensitive information.
I hope I have explained myself well.
Message was edited by:
bsmt

Could not access Local Session Bean using JNDI lookup

Hi EJB Guru,
I am quite new to EJB 3.0 but have had a good deal of success including using JNDI to lookup Remote Stateless Session Bean in EJB 3.0. However, looking up local Stateless Session Bean prove more challenging with I had anticipated.
Here is my code
as follows:
public interface Calculator {
    public int add(int x, int y);
    public int subtract(int x, int y);
import javax.ejb.Remote;
@Remote
public interface CalculatorRemote extends Calculator {
import javax.ejb.Local;
@Local
public interface CalculatorLocal extends Calculator {
import javax.ejb.Local;
import javax.ejb.Remote;
import javax.ejb.Stateless;
import bean.CalculatorLocal;
import bean.CalculatorRemote;
@Stateless
public class CalculatorBean implements CalculatorRemote, CalculatorLocal {
    public int add(int x, int y) {
        return x + y;
    public int subtract(int x, int y) {
        return x - y;
import bean.*;
import bean.Calculator;
import bean.CalculatorLocal;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class ClientAccessLocalCalculator {
    public static void main(String[] args) throws NamingException {
        InitialContext ctx = new InitialContext();
        CalculatorLocal calculator = (CalculatorLocal) ctx.lookup("CalculatorBean/local");
        System.out.println("1 + 1 = " + calculator.add(1, 1));
        System.out.println("1 - 1 = " + calculator.subtract(1, 1));    }
import bean.Calculator;
import bean.CalculatorRemote;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class ClientAccessRemoteCalculator {
    public static void main(String[] args) throws NamingException {
        InitialContext ctx = new InitialContext();
        CalculatorRemote calculator = (CalculatorRemote) ctx.lookup("CalculatorBean/remote");
        System.out.println("1 + 1 = " + calculator.add(1, 1));
        System.out.println("1 - 1 = " + calculator.subtract(1, 1));    }
}Output when running ClientAccessRemoteCalculator gives
1 + 1 = 2
1 - 1 = 0
Output when running ClientAccessLocalCalculator on JBoss AS 4.0.5 gives:
Exception in thread "main" javax.ejb.EJBException: Invalid invocation of local interface (null container)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:75)
at $Proxy0.add(Unknown Source) at ClientAccessLocalCalculator.main(ClientAccessLocalCalculator.java:14)
JNDIView in JMX-Console in JBoss:
+- CalculatorBean (class: org.jnp.interfaces.NamingContext)
| +- local (proxy: $Proxy84 implements interface bean.CalculatorLocal,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject)
| +- remote (proxy: $Proxy83 implements interface bean.CalculatorRemote,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBObject)
Output when running ClientAccessLocalCalculator on SJSAS 9.0 gives:
Exception in thread "main" javax.naming.NameNotFoundException: bean.CalculatorLocal not found
C:\>asadmin
Use "exit" to exit and "help" for online help.
asadmin> list-jndi-entries
Jndi Entries for server within root context:
bean.CalculatorRemote: javax.naming.Reference
jbi: com.sun.enterprise.naming.TransientContext
jdbc: com.sun.enterprise.naming.TransientContext
UserTransaction: com.sun.enterprise.distributedtx.UserTransactionImpl
bean.CalculatorRemote__3_x_Internal_RemoteBusinessHome__: javax.naming.Reference
bean.CalculatorRemote#bean.CalculatorRemote: javax.naming.Reference
ejb: com.sun.enterprise.naming.TransientContext
Command list-jndi-entries executed successfully.
asadmin>I am using Application Client to lookup these Session Beans on Netbeans 5.5, JBoss AS 4.0.5 (EJB3 installer)/SJSAS
9.0, SDK 1.5.0_11 on Windows XP platform.
Any assistance would be much appreciated.
Many thanks,
Henry

Hi Henry,
Any direct global JNDI lookup is not portable. It works in some cases but not in others, which
is why we recommend using the portable Java EE approach of declaring an ejb dependency
and looking up that dependency via the bean's component environment (java:comp/env).
This is true whether you're dealing with Remote or Local ejb dependencies.
Local ejbs are not supported in the Application Client tier at all. In the server tier, there is no
guarantee that a Local EJB even is assigned a global JNDI name since there's no requirement
that it be available outside of the application in which the ejb is defined.
You can find more information on these ejb access topics in our EJB FAQ :
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html

Problem accessing a session bean running on a different port

Hi,
I am using weblogic7.0 as the application server. I craeted two EJB's and
deployed them in two ports, port 7001 and 7378. I can access the beans when I
deploy them in the same port. But, I am having problem when EJB1 'server1' accesses
EJB2 'server2' deployed in port 7378. Below is the code I am using to lookup the
bean.
Properties prop = new Properties();
prop.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
prop.put(Context.PROVIDER_URL, "t3://localhost:7378");
Context ctx = new InitialContext(prop);
Object objref = ctx.lookup("java:comp/env/server2");
System.out.println("Inside the Object method "+objref);
iHome = (server2.InsertHome) objref;
System.out.println("Inside the iHome method "+iHome);
mInsert=iHome.create();
I am getting the following exception when I run the client. Can any one plaes
help me with the problem I am facing.
Thanks,
Ramya.
java.rmi.RemoteException: EJB Exception: ; nested exception is:
java.lang.NullPointerException
Start server side stack trace:
java.rmi.RemoteException: EJB Exception: ; nested exception is:
java.lang.NullPointerException
java.lang.NullPointerException
at server1.ConnectBean.insertName(ConnectBean.java:133)
at server1.ConnectBean_wtb7ta_EOImpl.insertName(ConnectBean_wtb7ta_EOIm
pl.java:45)
at server1.ConnectBean_wtb7ta_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServer
Ref.java:114)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServi
ceManager.java:785)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.ja
va:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteReques
t.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
End server side stack trace
; nested exception is:
java.lang.NullPointerException:
Start server side stack trace:
java.lang.NullPointerException
at server1.ConnectBean.insertName(ConnectBean.java:133)
at server1.ConnectBean_wtb7ta_EOImpl.insertName(ConnectBean_wtb7ta_EOIm
pl.java:45)
at server1.ConnectBean_wtb7ta_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServer
Ref.java:114)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServi
ceManager.java:785)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.ja
va:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteReques
t.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
End server side stack trace
at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutbound
Request.java:109)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
Ref.java:262)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
Ref.java:229)
at server1.ConnectBean_wtb7ta_EOImpl_WLStub.insertName(Unknown Source)
at server1.Client.example(Client.java:156)
at server1.Client.main(Client.java:168)
Caused by: java.lang.NullPointerException:
Start server side stack trace:
java.lang.NullPointerException
at server1.ConnectBean.insertName(ConnectBean.java:133)
at server1.ConnectBean_wtb7ta_EOImpl.insertName(ConnectBean_wtb7ta_EOIm
pl.java:45)
at server1.ConnectBean_wtb7ta_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServer
Ref.java:114)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServi
ceManager.java:785)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.ja
va:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteReques
t.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
End server side stack trace

So it looks like mInsert is null causing the NPE. I think you'll have
to debug this one.
-- Rob
Ramya wrote:
Hi Rob,
Thanks for your relpy. Below is the method which calls methods from the EJB2.
public void insertName(String name) throws Exception {
Connection con = null;
String name2="raj";
int num=30;
PreparedStatement ps = null;
CallableStatement cs=null;
String fName=null;
try {
System.out.println("In the insertName() before calling this.lookup()");
this.lookUp();
System.out.println("In the insertName() after calling this.lookup()");
con=mInsert.getConnection();
System.out.println("Inside the InsertName() in connectbean the value
of connect is"+con);
ps = con.prepareStatement("Insert into My_info values (?,?,?) ");
ps.setString(1, name);
ps.setString(2, "RamyaRAJ");
ps.setInt(3,30);
if (!(ps.executeUpdate() > 0)) {
String error = "insertName: MyInfoBean (" + fName + ") not updated";
throw new NoSuchEntityException (error);
else{
System.out.println("After calling execute upadte");
} catch(Exception e) {
System.out.println("There is an SQL insert exception in insertName()
method");
e.printStackTrace();
throw new EJBException (e);
} finally {
mInsert.cleanup(con, ps);//LINE NO 133
Line 133 (mInsert.cleanup(con, ps);) is the call to close up the SQL connection
that is from EJB2. mInsert is the member variable of the Remote class from EJB2.
Thanks,
Ramya.
Rob Woollen <[email protected]> wrote:
That looks like a NullPointerException in your code. You'd have to show
us line 133 of ConnectBean if you need help debugging it.
-- Rob
Ramya wrote:
Hi,
I am using weblogic7.0 as the application server. I craeted twoEJB's and
deployed them in two ports, port 7001 and 7378. I can access the beanswhen I
deploy them in the same port. But, I am having problem when EJB1 'server1'accesses
EJB2 'server2' deployed in port 7378. Below is the code I am usingto lookup the
bean.
Properties prop = new Properties();
prop.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
prop.put(Context.PROVIDER_URL, "t3://localhost:7378");
Context ctx = new InitialContext(prop);
Object objref = ctx.lookup("java:comp/env/server2");
System.out.println("Inside the Object method "+objref);
iHome = (server2.InsertHome) objref;
System.out.println("Inside the iHome method "+iHome);
mInsert=iHome.create();
I am getting the following exception when I run the client. Can anyone plaes
help me with the problem I am facing.
Thanks,
Ramya.
java.rmi.RemoteException: EJB Exception: ; nested exception is:
java.lang.NullPointerException
Start server side stack trace:
java.rmi.RemoteException: EJB Exception: ; nested exception is:
java.lang.NullPointerException
java.lang.NullPointerException
at server1.ConnectBean.insertName(ConnectBean.java:133)
at server1.ConnectBean_wtb7ta_EOImpl.insertName(ConnectBean_wtb7ta_EOIm
pl.java:45)
at server1.ConnectBean_wtb7ta_EOImpl_WLSkel.invoke(UnknownSource)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServer
Ref.java:114)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServi
ceManager.java:785)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.ja
va:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteReques
t.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
End server side stack trace
; nested exception is:
java.lang.NullPointerException:
Start server side stack trace:
java.lang.NullPointerException
at server1.ConnectBean.insertName(ConnectBean.java:133)
at server1.ConnectBean_wtb7ta_EOImpl.insertName(ConnectBean_wtb7ta_EOIm
pl.java:45)
at server1.ConnectBean_wtb7ta_EOImpl_WLSkel.invoke(UnknownSource)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServer
Ref.java:114)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServi
ceManager.java:785)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.ja
va:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteReques
t.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
End server side stack trace
at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutbound
Request.java:109)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
Ref.java:262)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
Ref.java:229)
at server1.ConnectBean_wtb7ta_EOImpl_WLStub.insertName(UnknownSource)
at server1.Client.example(Client.java:156)
at server1.Client.main(Client.java:168)
Caused by: java.lang.NullPointerException:
Start server side stack trace:
java.lang.NullPointerException
at server1.ConnectBean.insertName(ConnectBean.java:133)
at server1.ConnectBean_wtb7ta_EOImpl.insertName(ConnectBean_wtb7ta_EOIm
pl.java:45)
at server1.ConnectBean_wtb7ta_EOImpl_WLSkel.invoke(UnknownSource)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServer
Ref.java:114)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServi
ceManager.java:785)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.ja
va:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteReques
t.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
End server side stack trace

Exception while accessing deployed session bean

Hi,
I am new to IPlanet AS 6.0 . I wrote a simple stateless session bean in Forte EE v 3.0 environment. The compilation and deployment went fine. When I try to use my bean through a client program using IIOP then it throws the following exception in kjs:
javax.naming.NameNotFoundException: EjbContext: exception on getHome(), com.netscape.server.eb.UncheckedException: unchecked exception thrown by impl com.kivasoft.eb.boot.EBBootstrapImpl@71dc3d; nested exception is:
java.lang.NullPointerException
at com.netscape.server.ejb.EjbContext.createHomeRef(Unknown Source)
at com.netscape.server.ejb.EjbContext.getHomeRef(Unknown Source)
at com.netscape.server.ejb.EjbContext.lookup(Unknown Source)
at com.netscape.server.jndi.RootContext.lookup(Unknown Source)
at com.netscape.server.jndi.RootContext.lookup(Unknown Source)
at javax.naming.InitialContext.lookup(InitialContext. java:357)
at com.netscape.ejb.CorbaHomeFactoryImpl.ConstructEJBHome(Unknown Source
at com.netscape.CosNaming.NamingContextImpl.resolve(Unknown Source)
at org.omg.CosNaming._NamingContextImplBase.invoke(_N amingContextImplBas
e.java:233)
at com.sun.corba.ee.internal.corba.ServerDelegate.dis patch(ServerDelegat
e.java:236)
at com.sun.corba.ee.internal.iiop.ORB.process(ORB.jav a:227)
at com.sun.corba.ee.internal.iiop.CachedWorkerThread. doWork(IIOPConnecti
on.java:262)
at com.sun.corba.ee.internal.iiop.CachedWorkerThread. run(IIOPConnection.
java:230)
My client program is:
import java.util.*;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
public class MybeanClient {
public static void main(String[] args) {
try {
Properties env = new Properties();
env.put("java.naming.factory.initial","com.sun.jndi.cosnaming.CNCtxFactory");
env.put("java.naming.provider.url", "iiop://localhost:9010");
Context initial = new InitialContext(env);
Object objref = initial.lookup("ejb/Mybean");
MybeanHome home =(MybeanHome)PortableRemoteObject.narrow(objref,My beanHome.class);
Mybean bean = home.create();
String result = bean.test();
System.out.println(result);
} catch (Exception ex) {
System.err.println("Caught an unexpected exception!");
ex.printStackTrace();
The j2eeguide.converter sample bundled with IPlanet works fine with the above code.
The only difference is that the converter sample was deployed by the IAS deployment tool.
Mybean was deployed by the Forte.
What is the problem?
Any help would be highly appreciated.

1. Check that iiop is enabled in ias-ejb-jar.xml
2. Check your naming in the xml files
3. Check what has been deployed (filesystem & kregedit)
4. Try it with the full qualified name ejb/'ejbfilename'/<ejb-name>

Direct DB access from Session Bean w/o using Serialized Objects

I am developing a system where I am receiving some messages (data ) inside session bean and I want to log that data into data base �.i.e inserting that data in to various tables. I am not showing that data to client ( that is taken care by another application).
So I am directly calling insert methods on various tables instead of going for serialized classes for each of that tables and calling setter methods. Is this approach correct? Or this will create nightmares when millions of messages are to be logged? Do I have to make serialized objects? Please post the suggestions ..Thank you in advance.
If session bean is making direct inserts in the DB using Helper classes as shown below �is there any problem of concurrency?? Means multiple session bean instances inserting data in the same table using the helper class will create any problems?? I am using MySql db presently. Or all will work fine coz I am using the data source and pool available in welogic app server?
Is this a good approach if my application is doing inserts 90% of times? or I have to use entity beans or serialized objects encapsulating each class?
public class Logger implements SessionBean
DAO dao = getDAO();
dao.insertXyzLog(�x�, �y�,�.);
private DAO getDAO(){
if(Dao == null) {
oao = DAOFactory.getDAO();
return Dao;
//other std methods
public interface DAO {
// methods to directly insert data in to the tables
//some methods to look for required value in another tables
public abstract void insertXyzLog (String x, Stringy, ��.);
public class DAOImpl implements DAO {
// look up for JNDI data sourse
//method to return connection
public void insertXyzLog (String x, Stirng y�){
//SQLs for inserting into Xyz table using connection obtained above.

Hi,
Nothing wrong in using Helper class to insert into table. It won't create problem as long as your database server able to handle that many request from client.
If you use weblogic server and datasource, the server will take care of all connection pool management depending upon your configuration parameters.
Moreover, insert won't lock the table. So you need not worry about those things.
Best Luck,
Senthil Babu
Developer Technical Support
SUN Microsystems
http://www.sun.com/developers/support/

EJB 3.0 - Communicate an Applet with a Session Bean

Hello
I'm developing an EJB 3.0 app (eclipse and glassfish tools bundle), and I have an applet that has to use remote session beans.
QUESTION: Is it possible for the applet to connect to EJB?
QUESTION: By creating a J2EE application client project, can I use @EJB annotations to inject the session bean directly to the applet, avoiding the JNDI lookup?
(since I imagine that the anwser to the second one is NO, I do the following consideration)
Given an application client project, I imagine that this application can run remotely on a client machine/JRE. Then this application can use Annotations/injection facilities whenever it runs on a J2EE client container (which I assume consists of a set of libraries provided by the application server vendor, Glassfish in that case). Could this application be deployed using Java Web Start? If so, why can't it be deployed as an applet? (both options run in a client JRE, don't they?).
QUESTION: In either case (applet or JWS), how do I have to package the JAR file (using Eclipse) so that it contains the needed libraries for accessing the EJB? Which are those libraries?
At the time being, I'm trying to implement a sample application that follows the "Applet doing JNDI lookup" approach. I have:
- an EAR project
- an EJB project (containing an Entity Bean and a Stateless Session Bean with a @Remote interface)
@Remote
public interface HelloRemote {
     public String hello(String name);
@Stateless
public class Hello implements HelloRemote {
     @Override
     public String hello(String name) {
          return "Hello "+name+"!!";
}- an Application Client project (containing the applet code):
public class ClientApplet extends JApplet {
     public void init(){
          try {
               Context jndiContext = getInitialContext( );
               HelloRemote server = (HelloRemote) jndiContext.lookup(HelloRemote.class.getName());
               setContentPane(new JLabel(server.hello("Gerard")));
          } catch (NamingException e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
     private Context getInitialContext() throws NamingException{
          Properties props = new Properties();
          props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");
          props.setProperty("org.omg.CORBA.ORBInitialHost", "myhost");
          props.setProperty("org.omg.CORBA.ORBInitialPort", "3700");
          return new InitialContext(props);
}- a static web project (with a sample web page that contains the applet object the corresponding applet JAR file)
I tried to export the Application Client project as an "application client JAR", in the hope that the java EE libraries bundled with glassfish (listed as libraries of this project) would be packaged too.
No success, so now I'll try to copy all the JAR files (one by one) into the +\WebContent\+ folder of the Web Project, and add references to each of them in the archive="" attribute of the +<applet>+ HTML tag. Although this might work, I suspect that I am missing the good/easy way of doing it. Any suggestions?
Thanks in advance,
Gerard
Edited by: gsoldevila on May 6, 2009 7:09 AM

An Applet can communicate with an EJB via JNDI lookup but I would (personally) use an intermediate Servlet to handle this. Client to Servlet communication is http whereas to ejb is iiop - which might be blocked.
Injection only works in managed classes (EJB, Servlet, Listeners..) and an Application Client main class. So yes you could use an app client for handling resource injection.
m

Access session bean in ViewObjectImpl

Similar Messages

Maybe you are looking for