Using ejb ref

Hi !
I made an Entity bean for a master table, make its local interfaces and deploy it in a seperate jar.
Then i want to call this Entity bean thru any session bean using local interfaces and this session bean
is in a seperate jar file.
Right now its not working - i heard it can be used using <ejb-ref> tag.
Can anyone tell me what all entries do i need to make for this :
Do i need to write some code also for ti or only entries in deployment descriptor files will do ?
and what all entries do i need to make in deplyment descriptors or entity and deployment descriptors of session beans.
If somone has sample code then do please send across...
Thanks in advance !!

I tried the thing :
I made an Entity Bean and a session bean in seperate jar files
The ejb-ref entries in session beans deployment descriptor files are ::
<ejb-local-ref>
     <ejb-ref-name>ejb/EmpLocal</ejb-ref-name>
     <ejb-ref-type>Entity</ejb-ref-type>
     <local-home>EmpHomeLocal</local-home>
     <local>EmpLocal</local>
</ejb-local-ref>
Now, the code in session bean from where i am calling Entity bean is ::
InitialContext initialcontext = new InitialContext();
System.out.println("Initial Context created ");
home = (EmpHomeLocal)initialcontext.lookup("java:comp/env/EmpLocal");
System.out.println("After getting Local Home");
But its giving me the following error in Session Bean
Initial Context created
java.lang.ClassCastException: EmpEJB_1huw_LocalHomeImpl
Can, anyone help me to call an Entity bean's local methods from a Session bean - bith in seperate jar files

Similar Messages

  • Have to ask again:when to use ejb-ref ?

    hi, I asked this last week but nobody answered it.
    i am really curious about it and i checked some docs it said " it is useful
    coz beans can look each other up without needing to initialize JNDI to any
    particular driver".
    i wonder what means particular driver and when there will be great
    difference between using and not using.
    thanx in advance
    Ciao,
    zhxt

    In WLS you can have either global JNDI names that are visible throughout
    the server or JNDI names that are local to your application.
    The recommended best practice these days is to use ejb-refs and/or
    ejb-links to lookup your EJBs. For local EJBs, you don't need to have a
    global JNDI name since they are not visible to other applications.
    -- Rob
    scratchback wrote:
    hi, I asked this last week but nobody answered it.
    i am really curious about it and i checked some docs it said " it is useful
    coz beans can look each other up without needing to initialize JNDI to any
    particular driver".
    i wonder what means particular driver and when there will be great
    difference between using and not using.
    thanx in advance
    Ciao,
    zhxt

  • When to use ejb-ref?

    if i do not write <ejb-ref> in ejb-jar.xml,what will happen?the application
    can not run or performance is low?
    and is there any difference between bmp and cmp?i mean "does cmp need
    <ejb-ref>?"
    Ciao,
    zhxt

    In WLS you can have either global JNDI names that are visible throughout
    the server or JNDI names that are local to your application.
    The recommended best practice these days is to use ejb-refs and/or
    ejb-links to lookup your EJBs. For local EJBs, you don't need to have a
    global JNDI name since they are not visible to other applications.
    -- Rob
    scratchback wrote:
    hi, I asked this last week but nobody answered it.
    i am really curious about it and i checked some docs it said " it is useful
    coz beans can look each other up without needing to initialize JNDI to any
    particular driver".
    i wonder what means particular driver and when there will be great
    difference between using and not using.
    thanx in advance
    Ciao,
    zhxt

  • Client using ejb-ref to lookup

    Hi,
         I read the docs, I searched for answers but there are still some things I don't
    understand regarding a stand alone client application to a weblogic server 8.1
    that could look up a bean using ejb-ref. I don't want to use the JNDI name.
         There is the client-application.xml and the MyClientJar.runtime.xml but i'm not
    sure I understand where to put them. I have the client-application.xml in my
    client jar, the runtime.xml one in the same directory like specified in the
    documentation, I tried to put the xml and the jar in my classpath and running
    the client, no success the client cannot lookup using ejb-ref
         I read that MyClientJar.jar should go in my ServerModule.ear so I did that too,
    still doesn't work.
         Something I'm not doing right or something I don't understand.
         Any help or comments appreciated
         Thank You
         Max

    Hi,
         I read the docs, I searched for answers but there are still some things I don't
    understand regarding a stand alone client application to a weblogic server 8.1
    that could look up a bean using ejb-ref. I don't want to use the JNDI name.
         There is the client-application.xml and the MyClientJar.runtime.xml but i'm not
    sure I understand where to put them. I have the client-application.xml in my
    client jar, the runtime.xml one in the same directory like specified in the
    documentation, I tried to put the xml and the jar in my classpath and running
    the client, no success the client cannot lookup using ejb-ref
         I read that MyClientJar.jar should go in my ServerModule.ear so I did that too,
    still doesn't work.
         Something I'm not doing right or something I don't understand.
         Any help or comments appreciated
         Thank You
         Max

  • Help needed - why we use ejb-ref element in ejb-jar.xml

    hi all
    can anyone tell me what is the purpose of this element in the ejb deploy descriptor? thanks

    Suppose u have bean A, which needs to look up another bean B. Normally you wud need to use the jndi lookup using the initial context to access the bean B's home interface. If you use ejb-ref element you dont need to know the JNDI name of bean B. You can use ejb-ref-name instead. So you can say this is a short cut method of looking up and getting a reference to a bean's home object.

  • Using ejb-ref tag for EJB toEJB reference

    Hello all respected members,
    I am using weblogic 5.1 (sp 9).
    I have two Session EJBs - a client and another is the referenced by
    the client.
    The client is using services of the referenced EJB.
    The two EJBs are in two very different packages.
    Now say I am trying to deploy the client EJB first, without deploying
    the referenced EJB.
    What I expect (rather, want)is, when the client EJB is being deloyed,
    it should give a notification somehow (let's say, by throwing an
    exception) that the referenced EJB is not yet deployed.
    First of all, is this possible ?
    Secondly, I am aware of the of the <ejb-ref> tag. In order to meet my
    requirement, I have added the same tag in the client's ejb-jar.xml and
    corresponding <ejb-reference-description> tag in the
    weblogic-ejb-jar.xml file.
    When I start the weblogic server, I can see that the referenced EJB is
    not deployed. But the client EJB is being deployed, it does not give
    any notification that the referenced EJB is not yet deployed and gets
    deployed successfully.
    In other words, I expect <ejb-ref> tag to let me know that the
    referenced EJB is not yet deployed. Is my understanding of <ejb-ref>
    tag correct ?
    It is clear to me that when the client EJB tries to instantiate the
    referenced EJB to use its services, it would throw an exception
    (during the lookup) since the referenced EJB is not deployed. But I
    want to avoid this exception at this stage. I want to get a
    notification of this, much before i.e. when the weblogic is deploying
    my client EJB. I think the <ejb-ref> tag does this. Hence I am using
    it.
    If I am going in wrong direction, is there any other way to fulfil my
    requirement ?
    Please advise.
    Neelesh.

    The <ejb-ref> element is used at deployment to map the bean references.
    The beans referred to should already be deployed.
    Neelesh wrote:
    Hello all respected members,
    I am using weblogic 5.1 (sp 9).
    I have two Session EJBs - a client and another is the referenced by
    the client.
    The client is using services of the referenced EJB.
    The two EJBs are in two very different packages.
    Now say I am trying to deploy the client EJB first, without deploying
    the referenced EJB.
    What I expect (rather, want)is, when the client EJB is being deloyed,
    it should give a notification somehow (let's say, by throwing an
    exception) that the referenced EJB is not yet deployed.
    First of all, is this possible ?
    Secondly, I am aware of the of the <ejb-ref> tag. In order to meet my
    requirement, I have added the same tag in the client's ejb-jar.xml and
    corresponding <ejb-reference-description> tag in the
    weblogic-ejb-jar.xml file.
    When I start the weblogic server, I can see that the referenced EJB is
    not deployed. But the client EJB is being deployed, it does not give
    any notification that the referenced EJB is not yet deployed and gets
    deployed successfully.
    In other words, I expect <ejb-ref> tag to let me know that the
    referenced EJB is not yet deployed. Is my understanding of <ejb-ref>
    tag correct ?
    It is clear to me that when the client EJB tries to instantiate the
    referenced EJB to use its services, it would throw an exception
    (during the lookup) since the referenced EJB is not deployed. But I
    want to avoid this exception at this stage. I want to get a
    notification of this, much before i.e. when the weblogic is deploying
    my client EJB. I think the <ejb-ref> tag does this. Hence I am using
    it.
    If I am going in wrong direction, is there any other way to fulfil my
    requirement ?
    Please advise.
    Neelesh.

  • Ejb-ref in oc4j 10.1.3.2.0 standalone

    Hi,
    i asked this before, but i didnt receive any answers. So i looked in more deeply to be more precise.
    I developed and deployed a Webservice with JDEV 10.1.3 which looks up EJBs in a remote oc4j. I configured the ejb-references in web.xml and orion-web.xml like shown in the documentation by using ejb-ref-mapping attribute jndi-properties-file and remote-server-ref=true. That works fine in embedded oc4j 10.1.3.2.0.
    If i deploy the same application to standalone oc4j 10.1.3.2.0 the application fails wih a naming exception. If i hardcode the jndi-properties again all works fine, so it seems to be a problem of configuration.
    So i let print out some information about the InitialContext constructed im the ServiceLocator-Class i use:
    ctx = new InitialContext( );
    Hashtable ha = ResourceManager.getInitialEnvironment(null);
    logger.debug("" + ha.get(InitialContext.PROVIDER_URL));
    NamingEnumeration nenum = ctx.listBindings("java:comp/env");
    There are indeed some differences between the standalone and the embedded as listed below:
    embedded:
    07/09/17 17:53:36 ormi://remote-IP: javax.naming.Reference:Reference Class Name: javax.ejb.EJBHome
    Type: location
    Content: MyBeanFacade
    Type: remote-server-ref
    Content: true
    Type: jndi-properties-file
    Content: jndi.properties
    07/09/17 17:53:36 ejb: javax.naming.Context:[Context TestWS-org-webapp: {MyBeanFacade=Reference Class Name: javax.ejb.EJBHome
    Type: location
    Content: MyBeanFacade
    Type: remote-server-ref
    Content: true
    Type: jndi-properties-file
    Content: jndi.properties
    , ejb/MBeanServerUserEjb=Reference Class Name: javax.ejb.EJBHome
    Type: location
    Content: MBeanServerUserEjb
    standalone:
    07/09/17 18:14:06 ormi://IP-ofTheHostOfOC4J:23791/default
    07/09/17 18:14:06 MyBeanFacade: javax.naming.Reference:Reference Class Na
    me: javax.ejb.EJBHome
    Type: location
    Content: MyBeanFacade
    07/09/17 18:14:06 ejb: javax.naming.Context:[Context webapp: {MyBeanFacad
    e=Reference Class Name: javax.ejb.EJBHome
    Type: location
    Content: MyBeanFacade
    , ejb/MBeanServerUserEjb=Reference Class Name: javax.ejb.EJBHome
    Type: location
    Content: MBeanServerUserEjb
    The difference is obvious.
    Interestingly http://www.oracle.com/technology/oracleas/schema/orion-web-10_0.xsd
    dosnt neither define jndi-properties-file nor remote-server-ref for ejb-ref-mapping. On the other hand, thats what one finds in the documentation.
    Another problem is, that originally the oc4j tried to lookup with protocol ormis.
    So i had first to delete ssl-port = "23943" from rmi.xml to see ormi.
    Now on the first call of the Web Service after start of the server in fact the lookup goes to the remote-IP not to the IP-ofTheHostOfOC4J as written before. But the lookup fails with a namingexception anyway. After the second call the lookup goes to IP-ofTheHostOfOC4J again, even though the application is restarted or redeployed.
    Its not very funny to go through this configuration issues with every new revision of the software. Perhaps the lack of feedback in this forum is a hint to open more often a tar than to post herein.
    Regards chris                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

    Thank u both for your answers.
    First of all this is not a Web Service specific issue at all, its about configuring ejb-references for web-components.
    The difference was between embedded and standalone.
    The reason for this behavior is a bug in 10.1.3.1 standalone.
    I think this could be fixed in this 1/2 GB patch from july 2007, so why not upgrading to 10.1.3.3 for which i assume that it includes the fix as Olaf proposed following my proposal ;-)
    Anyway you can work around it quite simple:
    The reason is that during the deployment the contents of the custom (contained in the ear-file) orion-web.xml is not properly added to the generated orion-web.xml in applications-deployments.
    The ejb-remote attrbiute is discarded.
    So just add it to the generated orion-web.xml after the deployment and restart the oc4j. Dont redeploy or restart the application cause a redopleyment would overwrite your changes.
    Thanks for my help :-)
    Chris

  • Error starting WL - weblogic.xml.dom.ChildCountException: missing child home in ejb-ref

    hi,
    i get this following error when i start the WL 7.0. The web application fails
    to start but the ejbs are started properly. This is an example from the Monson
    Haefel book, on the CMP: Entity bean relationships.
    Can anybody tell me what is happening ??
    -thanks
    -vasanth
    Error log:
    =============
    <Error> <HTTP> <101179> <[HTTP] Error parsing des criptor in Web appplication
    "C:\bea\user_projects\mydomain\.\myserver\.wlnotdele
    te\titan\titan.war" [Path="C:\eclipse\workspace\titan4\dist\titan.ear", URI="tit
    an.war"
    weblogic.xml.dom.ChildCountException: missing child home in ejb-ref
            at weblogic.xml.dom.DOMUtils.getElementByTagName(DOMUtils.java:147)
            at weblogic.xml.dom.DOMUtils.getValueByTagName(DOMUtils.java:128)
            at weblogic.servlet.internal.dd.EJBReference.<init>(EJBReference.java:61
            at weblogic.servlet.internal.dd.WebAppDescriptor.<init>(WebAppDescriptor
    .java:247)
            at weblogic.servlet.internal.dd.DescriptorLoader.initializeWebXml(Descri
    ptorLoader.java:540)
            at weblogic.servlet.internal.dd.DescriptorLoader.<init>(DescriptorLoader
    .java:253)
            at weblogic.servlet.internal.dd.DescriptorLoader.<init>(DescriptorLoader
    .java:215)
            at weblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.ja
    va:282)
            at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:714)
            at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:555)
            at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:458)
            at weblogic.management.deploy.slave.SlaveDeployer.prepareAllStagedApplic
    ations(SlaveDeployer.java:490)
            at weblogic.management.deploy.slave.SlaveDeployer.initialize(SlaveDeploy
    er.java:253)
            at weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.initi
    alize(DeploymentManagerServerLifeCycleImpl.java:150)
            at weblogic.t3.srvr.ServerLifeCycleList.initialize(ServerLifeCycleList.j
    ava:54)
            at weblogic.t3.srvr.T3Srvr.initialize1(T3Srvr.java:782)
            at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:594)
            at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:282)
            at weblogic.Server.main(Server.java:32)
    >
    <Jun 23, 2003 10:10:51 AM CDT> <Error> <Deployer> <149205> <The Slave Deployer
    f
    ailed to initialize the application titan due to error weblogic.management.Appli
    cationException: Prepare failed. Task Id = null
    Module Name: titan.war, Error: Could not load web application from 'C:\bea\user_
    projects\mydomain\.\myserver\.wlnotdelete\titan\titan.war'
    weblogic.management.ApplicationException: Prepare failed. Task Id = null
    Module Name: titan.war, Error: Could not load web application from 'C:\bea\user_
    projects\mydomain\.\myserver\.wlnotdelete\titan\titan.war'
    at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:720)
    at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:555)
    at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:458)
    at weblogic.management.deploy.slave.SlaveDeployer.prepareAllStagedApplic
    ations(SlaveDeployer.java:490)
    at weblogic.management.deploy.slave.SlaveDeployer.initialize(SlaveDeploy
    er.java:253)
    at weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.initi
    alize(DeploymentManagerServerLifeCycleImpl.java:150)
    at weblogic.t3.srvr.ServerLifeCycleList.initialize(ServerLifeCycleList.j
    ava:54)
    at weblogic.t3.srvr.T3Srvr.initialize1(T3Srvr.java:782)
    at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:594)
    at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:282)
    at weblogic.Server.main(Server.java:32)
    >

    It is working now.
    For a local entity bean, i was using <ejb-ref> instead of <local-ejb-ref>
    Once i changed that, it worlked.
    thanks
    -vasanth
    "Sanjeev Chopra" <[email protected]> wrote:
    correct url for doc...
    http://e-docs.bea.com/wls/docs81/webapp/web_xml.html#1020090
    "Sanjeev Chopra" <[email protected]> wrote in message
    news:[email protected]...
    Seems like titan.war's WEB-INF/web.xml has an ejb-ref element witha
    missing
    <home> element .
    see http://e-docs/wls/docs81/webapp/web_xml.html#1020090
    "Vasanth" <[email protected]> wrote in message
    news:[email protected]...
    hi,
    i get this following error when i start the WL 7.0. The web applicationfails
    to start but the ejbs are started properly. This is an example from
    the
    Monson
    Haefel book, on the CMP: Entity bean relationships.
    Can anybody tell me what is happening ??
    -thanks
    -vasanth
    Error log:
    =============
    <Error> <HTTP> <101179> <[HTTP] Error parsing des criptor in Webappplication
    "C:\bea\user_projects\mydomain\.\myserver\.wlnotdele
    te\titan\titan.war" [Path="C:\eclipse\workspace\titan4\dist\titan.ear",URI="tit
    an.war"
    weblogic.xml.dom.ChildCountException: missing child home in ejb-ref
    atweblogic.xml.dom.DOMUtils.getElementByTagName(DOMUtils.java:147)
    at
    weblogic.xml.dom.DOMUtils.getValueByTagName(DOMUtils.java:128)
    atweblogic.servlet.internal.dd.EJBReference.<init>(EJBReference.java:61
    atweblogic.servlet.internal.dd.WebAppDescriptor.<init>(WebAppDescriptor
    java:247)
    atweblogic.servlet.internal.dd.DescriptorLoader.initializeWebXml(Descri
    ptorLoader.java:540)
    atweblogic.servlet.internal.dd.DescriptorLoader.<init>(DescriptorLoader
    java:253)
    atweblogic.servlet.internal.dd.DescriptorLoader.<init>(DescriptorLoader
    java:215)
    atweblogic.servlet.internal.WebAppModule.loadDescriptor(WebAppModule.ja
    va:282)
    atweblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:714)
    atweblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:555)
    atweblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:458)
    atweblogic.management.deploy.slave.SlaveDeployer.prepareAllStagedApplic
    ations(SlaveDeployer.java:490)
    atweblogic.management.deploy.slave.SlaveDeployer.initialize(SlaveDeploy
    er.java:253)
    atweblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.initi
    alize(DeploymentManagerServerLifeCycleImpl.java:150)
    atweblogic.t3.srvr.ServerLifeCycleList.initialize(ServerLifeCycleList.j
    ava:54)
    at weblogic.t3.srvr.T3Srvr.initialize1(T3Srvr.java:782)
    at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:594)
    at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:282)
    at weblogic.Server.main(Server.java:32)
    >
    <Jun 23, 2003 10:10:51 AM CDT> <Error> <Deployer> <149205> <The SlaveDeployer
    f
    ailed to initialize the application titan due to errorweblogic.management.Appli
    cationException: Prepare failed. Task Id = null
    Module Name: titan.war, Error: Could not load web application from'C:\bea\user_
    projects\mydomain\.\myserver\.wlnotdelete\titan\titan.war'
    weblogic.management.ApplicationException: Prepare failed. Task Id
    = null
    Module Name: titan.war, Error: Could not load web application from'C:\bea\user_
    projects\mydomain\.\myserver\.wlnotdelete\titan\titan.war'
    atweblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:720)
    atweblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:555)
    atweblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContain
    er.java:458)
    atweblogic.management.deploy.slave.SlaveDeployer.prepareAllStagedApplic
    ations(SlaveDeployer.java:490)
    atweblogic.management.deploy.slave.SlaveDeployer.initialize(SlaveDeploy
    er.java:253)
    atweblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.initi
    alize(DeploymentManagerServerLifeCycleImpl.java:150)
    atweblogic.t3.srvr.ServerLifeCycleList.initialize(ServerLifeCycleList.j
    ava:54)
    at weblogic.t3.srvr.T3Srvr.initialize1(T3Srvr.java:782)
    at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:594)
    at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:282)
    at weblogic.Server.main(Server.java:32)
    >

  • Ejb-ref element references to other beans

    Hello,
    Can anyone tell me what ejb references to other beans are for? (ejb-ref element).
    I am completely missing the point and would be grateful if someone could tell me why I should have the overhead of writing this:
    <ejb-ref>
    <ejb-ref-name>ejb/waUserMgr</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <home>com.reuters.pds.webapp.bl.user.api.WAUserMgrHome</home>
    <remote>com.reuters.pds.webapp.bl.user.api.WAUserMgr</remote>
    <ejb-link>WAUserMgrEJB</ejb-link>
    </ejb-ref>
    Any comment welcome..
    Julien.

    Hi,
    The <ejb-ref> element is optional, you could use the actual JNDI name instead.
    The advantage with using <ejb-ref> is that, if you deploy the bean on another server, probably with a different JNDI name,
    your code can still continue using the same name as defined by <ejb-ref-name>.
    Internally, the <ejb-ref-name> will be mapped to the actual JNDI location, maybe using symbolic links.

  • Ejb-ref, ejb-link or JNDI lookup

    If I have an application in which one EJB is using another EJB in the SAME application,
    what is the best of way of accessing the other EJB?
    Why would I use ejb-ref / ejb-link instead of just looking it up in the JNDI?
    Just curious.
    Thanks.
    Dan

    ejb-ref/ejb-link were introduced in the ejb spec to allow bean developers to
    develop beans without any knowledge of the environment into which they would
    be deployed. If you can live with hard coded jndi names then that is fine or
    you can use the mechanism define below but using ejb-ref/ejb-link makes your
    beans more reuseable and less dependent on the final environement.
    If both the ejbs are in the same application I would recommend using ejb-ref
    and ejb-link.
    -- Anand
    "Chad McDaniel" <[email protected]> wrote in message
    news:[email protected]..
    "Dan Baumbach" <[email protected]> writes:
    If I have an application in which one EJB is using another EJB in the
    SAME application,
    what is the best of way of accessing the other EJB?
    Why would I use ejb-ref / ejb-link instead of just looking it up in theJNDI?
    >>
    >
    I believe that ejb-ref/link is not useful in most systems and causes
    another level of complexity to maintain. Since EJBs are complex enough
    I think that using the basic JNDI lookup is preferable. Also, this
    frees you to move the beans to a remote server if you ever want to.
    The simplest and most flexible technique, I believe, is to use a
    utility class that handles all EJB lookups for you and use a simple
    EJB and JNDI name mapping that this class can generate the JNDI name
    with a simply manipulation of the bean name. If you ever change the
    reference technique you will then only have one class to modify.
    This is also a good place to cache home references.

  • How to lookup EJB3 beans using JNDI names without defining ejb-ref in DD?

    Hi Kenneth,
    I am just continuing the topic:
    How Lookup SLSB from other SLSB? <HELP>
    http://forum.java.sun.com/thread.jspa?threadID=5117484&tstart=0
    (my original forums account failed, so I am using new one)
    if I am not seeking portability I should be able to lookup a bean directly through JNDI without using the ejb-ref. (I just want to see how it can be done)
    http://forum.java.sun.com/thread.jspa?forumID=13&threadID=751907
    http://www.theserverside.com/discussions/thread.tss?thread_id=16402
    I am using SJSAS PE 9.0 I am failing to lookup my beans from other beans directly without ejb-ref.
    Is there some sample code to look at?
    Thanks!

    Global JNDI names are vendor-specific and not known until deployment time. That is one
    of the main reasons the Java EE component environment model defines a level of
    indirection for accessing component dependencies. It is best to use either an ejb-ref
    or @EJB annotation when accessing EJBs from a Java EE component.
    If you choose not to, you just have to make sure the global JNDI name you use matches
    the one assigned to the target EJB. We have a lot of information on how this works
    in our EJB FAQ.
    https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
    If you're still encountering an error, please provide more specifics about your application,
    the code you're using for the lookup, and the error message you're receiving. Just
    saying "my looking fails" doesn't help us diagnose the problem :-)
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Could not lookup PortalManagerHome in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager

    Hi
    I am just a starter on WLPortal.
    I have created a barebone Application from scratch. I have synchronized it properly
    from EBCC to WLP. But When I am trying to access the home page of my application,
    I am getting from stack trace -
    <Nov 6, 2002 5:37:59 PM IST> <Error> <PortalAppflow> <Could not lookup PortalManagerHome
    in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager.
    javax.naming.NameNotFoundException: Unable to resolve comp/env/ejb/PortalManager
    Resolved: 'comp/env' Unresolved:'ejb' ; remaining name 'PortalManager'
    at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:802)
    at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:209)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:173)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:181)
    at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:181)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:323)
    at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(ReadOnlyContextWrapper.java:36)
    at weblogic.jndi.internal.AbstractURLContext.lookup(AbstractURLContext.java:124)
    at javax.naming.InitialContext.lookup(InitialContext.java:350)
    at com.bea.p13n.util.JndiHelper.lookupNarrow(JndiHelper.java:96)
    at com.bea.portal.appflow.PortalAppflowHelper.<clinit>(PortalAppflowHelper.java:64)
    at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.init(PortalWebflowServlet.java:78)
    at javax.servlet.GenericServlet.init(GenericServlet.java:258)
    at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java:700)
    at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.java:643)
    at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:588)
    at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:368)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:242)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
    at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:215)
    at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
    at jsp_servlet.__index._jspService(__index.java:92)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:304)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2459)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    >
    <Nov 6, 2002 5:37:59 PM IST> <Error> <HTTP> <[WebAppServletContext(19695286,FirstWebApp,/FirstWebApp)]
    Servlet failed with Exception
    java.lang.NullPointerException:
    at com.bea.portal.appflow.PortalAppflowHelper.createPortalManager(PortalAppflowHelper.java:82)
    at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.setupPortalRequest(PortalWebflowServlet.java:187)
    at com.bea.portal.appflow.servlets.internal.PortalWebflowServlet.doGet(PortalWebflowServlet.java:99)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
    at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:215)
    at weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:112)
    at jsp_servlet.__index._jspService(__index.java:92)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:304)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2459)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2039)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    When I decompiled the class PortalAppflowHelper, I found a static block in it,
    which was as under-
    static
    debug = Debug.getInstance(com.bea.portal.appflow.PortalAppflowHelper.class);
    try
    if(debug.ON)
    debug.out("Looking up PortalManagerHome using EJB reference java:comp/env/ejb/PortalManager");
    portalManagerHome = (PortalManagerHome)JndiHelper.lookupNarrow("java:comp/env/ejb/PortalManager",
    com.bea.portal.manager.ejb.PortalManagerHome.class);
    if(debug.ON)
    debug.out("Successfully retrieved PortalManagerHome " + portalManagerHome);
    catch(Exception e)
    PortalAppflowLogger.errorFindingPortalManagerHome("java:comp/env/ejb/PortalManager",
    e);
    I have checked the PortalManager's JNDI name on WLConsole. Its ${APPNAME}.BEA_portal.PortalManager.
    Should I change it?
    When I tried to change it, I started getting other weird errors.
    Thanks
    Neeraj Hans

    Neeraj -
    The Portal framework code (including PortalAppflowHelper) uses ejb
    references to find the PortalManager (and other EJBs) from servlets and
    taglibs; that is what is signified by the java:comp/env/... name.
    Since you built your webapp from scratch (instead of using the portal
    wizard), you will need to make sure the you have the appropriate
    <ejb-ref> entries in your web.xml, and the corresponding
    <ejb-reference-description> entries in your weblogic.xml. By default,
    you will need at least mappings for:
    - ejb/PortalManager
    - ejb/UserManager
    - ejb/GroupManager
    - ejb/PipelineExecutor
    - ejb/EventService
    See either the resulting webapp from using the portal wizard or
    BEA_HOME/weblogic700/samples/portal/sampleportalDomain/beaApps/sampleportal/sampleportal/WEB-INF
    for example syntax.
    Greg
    Neeraj Hans wrote:
    Hi
    I am just a starter on WLPortal.
    I have created a barebone Application from scratch. I have
    synchronized it properly
    from EBCC to WLP. But When I am trying to access the home page of my
    application,
    I am getting from stack trace -
    <Nov 6, 2002 5:37:59 PM IST> <Error> <PortalAppflow> <Could not lookup
    PortalManagerHome
    in the JNDI tree using EJB reference java:comp/env/ejb/PortalManager.
    javax.naming.NameNotFoundException: Unable to resolve
    comp/env/ejb/PortalManager
    Resolved: 'comp/env' Unresolved:'ejb' ; remaining name 'PortalManager'
    at <stack trace lines snipped>
    When I decompiled the class PortalAppflowHelper, I found a static
    block in it,
    which was as under-
    static
    debug =
    Debug.getInstance(com.bea.portal.appflow.PortalAppflowHelper.class);
    try
    if(debug.ON)
    debug.out("Looking up PortalManagerHome using EJB
    reference java:comp/env/ejb/PortalManager");
    portalManagerHome =
    (PortalManagerHome)JndiHelper.lookupNarrow("java:comp/env/ejb/PortalManager",
    com.bea.portal.manager.ejb.PortalManagerHome.class);
    if(debug.ON)
    debug.out("Successfully retrieved PortalManagerHome "
    + portalManagerHome);
    catch(Exception e)
    PortalAppflowLogger.errorFindingPortalManagerHome("java:comp/env/ejb/PortalManager",
    e);
    I have checked the PortalManager's JNDI name on WLConsole. Its
    ${APPNAME}.BEA_portal.PortalManager.
    Should I change it?
    When I tried to change it, I started getting other weird errors.
    Thanks
    Neeraj Hans

  • Using local session bean interface from web container using EJB 3.0

    Hi,
    How can you use a local session bean interface from Java (rather than data controls) in a web container using EJB 3.0?
    I can use a remote interface by looking up InitialContext, but I can't find a local interface this way (even from another session EJB). I can use a local interface from an EJB using annotation "EJB", but as I understand, this is not available in the web container.
    If I try to add an ejb-jar.xml file, these seems to mess up by project...
    Hope you can help.
    Roger

    The portable way to retrieve an EJB reference in Java EE is to either inject it or look it up via the
    component's private naming environment. The simplest way is :
    @EJB
    private DocumentManager dm;
    The global JNDI name is only used as an implementation specific way to uniquely assign an
    identifier to a specific Remote EJB. It's best for this not to appear directly in the source code.
    There's more on global JNDI names in our EJB FAQ :
    https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
    The alternative to annotations is to use an ejb-ref to declare the ejb dependency. The ejb-ref
    is declared in the standard deployment descriptor corresponding to the component doing the
    lookup. Each ejb-ref has an ejb-ref-name, e.g. <ejb-ref-name>DM_ref</ejb-ref-name>
    The code looks up the ejb-ref-name relative to the java:comp/env namespace to retrieve the
    EJB reference.
    DocumentManager dm = (DocumentManager)
    new InitialContext().lookup("java:comp/env/DM_ref");

  • Using EJBs in Web Dynpro

    I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
    What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro</a>).
    I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
    I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
    - <b>It violates the MVC paradigm</b> by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
    - <b>Doesn't carry its own weight.</b> In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
               CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
    Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
    - <b>Unnecessarily complicates error handling</b>. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
    To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
    - <b>Produces unnecessary DCs</b>. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
    - <b>Not a typical application of the Command pattern</b>. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
    - specify, queue and execute requests at different times
    - decouple execution of a command from its invoker
    - support undo operations
    - support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
    None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
    At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

    Thanks for your reply and your suggestion. I have posted in the Web Dynpro Java forum... and suggest those wishing to participate in this thread to refer to the Web Dynpro Java forum.
    As for your answer, I'm afraid it doesn't satisfy me.
    Reuse is hardly an issue, since the CommandBean is specifically tailor-made for the Web Dynpro application that needs to use it. I could hardly imagine building another application that would just happen to have the exact same needs as far as data structure and processing is concerned...
    As for the right Eclipse environment... the CommandBean is not an EJB artifact - it is an EJB client. The aforementioned tutorial in fact suggests creating it in the Java perspective.
    But thanks anyway for your time and suggestion

  • Using EJBs in Web Dynpro Applications

    I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
    What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro Applications</a>).
    I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
    I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
    - <b>It violates the MVC paradigm</b> by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
    - <b>Doesn't carry its own weight</b>. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
    CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
    Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
    - <b>Unnecessarily complicates error handling</b>. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
    To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
    - <b>Produces unnecessary DCs</b>. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
    - <b>Not a typical application of the Command pattern</b>. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
    - specify, queue and execute requests at different times
    - decouple execution of a command from its invoker
    - support undo operations
    - support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
    None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
    At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

    Hi Romeo,
    You would be disappointed, this reply ain't anywhere nearby to what you are talking about...
    I wanted to mail you, but you have not mentioned your email in your profile.
    I am really impressed by your flair for writing. It would be far better had you written a blog on this topic. Believe me, it would really be better. There is a much wider audience waiting out there to read your views rather than on the forums. This is what I believe. To top it, you would be rewarded for writing something like this from SDN. On the blogs too, people can comment and all, difference being there you would be rewarded by SDN, here people who reply to you would be rewarded by you. Doesn't make  much a difference.
    Anyways the ball is still in your court
    As far as I am concerned, it has still not been much time since I have started working on Web Dynpro. So can't really comment on the issue...
    Bye
    Ankur

Maybe you are looking for

  • Customer Receivables Ageing Report

    Hi experts, Our SAP version is 2005B PL 43. The Customer receivable Ageing Report has two tabs- By Journal entries tab and By sales Documents tab. 1. We find that all Payments, Credit notes and Invoices appear in the Customer Ageing Report By Journal

  • Symptom mimics cross domain problem

    We are having a problem loading content into a swf file in the QA environment, even though the application worked fine in our local development environment. Even though the content is being loaded from the same domain as the swf file, we followed adv

  • BI Content version issue

    Dear All, We are installed ECC 6 EHP 4 Ready solution and tthen upgrade into EHP5.BW is part of ECC6 that is why we create a new client and assigned a BW client for example client 300. Now issue is that we don't have BI Content in Add-on installed. o

  • HTTPServlet and Threads

    Hi, I am searching for confirmation here. What i want to do is to start a background process upon a request to HTTPServler. However, I want to result an HTTPResponse straight away, but i want as well to insure that no matter what, the background thre

  • Call processing in duplex pairs of Routers

    Hi , I would like to completely understand the call  processing in a duplex pair of  ICM routers (say Router A and Router B) .  How will the OPC know to which router the call has to be sent ?  Please  let me know. Regards, Deepak