Why is there no EJB modules generated in chapter 10 of Medrec Tutorial?

Hi,
I am going through the sample Medical Records Development Tutorial.
In Chapter 10,after going through the Procedure 3..I couldn't see any EJB Module being deployed at http://localhost:7101/console/Deployments/EJB Modules
.Any clue what is going wrong??
Thanks in Advance
Natasha

Natasha: Are the EJBs being deployed within an EAR? If so, check under
deployed Applications in the console.
"Natasha" <[email protected]> wrote in message
news:40a908dd$[email protected]..
Hi,
I am going through the sample Medical Records Development Tutorial.
In Chapter 10,after going through the Procedure 3..I couldn't see any EJBModule being deployed at http://localhost:7101/console/Deployments/EJB
Modules
.Any clue what is going wrong??
Thanks in Advance
Natasha

Similar Messages

Is there any function module that generates date of 30th september of next

is there any function module that generates date of 30th september of next year.?

May be u mean...20100930
You can simply
Add 10000 to this years sept 30...If you want sept 30 from today...
Data: G_DATE Type Sy-DATUM.
G_DATE = Sy-DATUM.
G_DATE+4(02) = '09'.
G_DATE+6(02) = '30'.
G_DATE0(04) = G_DATE0(04) + 1.
Santhosh

Error while building a Webservice in Netbeans EJB Module

I have copied the java code of a JCD doing xml to cobol copybook transformation in JCAPS, to a new webservice created in the Netbeans EJB module. There were no compilation errors. But while trying to build, I am getting errors like "java.io.printStream does not have a no-arg default Constructor" , "IllegalAnnotation Exception", "Unable to create jaxb context" etc..
I am not able to find out why this happened... Someone please help me in resolving this issue......

Guys,
I am able to solve the problem. I think the problem is Language settings difference between Database and OWB repository.

How to reference an External Library (Server Side) in a DC-EJB Module ?

Hi:
I start working with hibernate in a DC component, so I create my DC project and EJB module inside. I Make an external library following this
Thanks a lot for your time on this thread.
Rocío.

Hi Rocío!
Umm, I don't usually use DC's... I don't know if this will work... you can make an EAR (New Proyect -> J2EE -> Enterpise Application Module), add your EJB Module to the EAR (right click on EJB Project and choose Add to EAR proyect), and you'll find a j2ee-engine file on it, and you can add the reference there.Then deploy the EAR.
I normally do something similar to your issue, I make a EJB calling XI via Java Proxys, and the reference to the XI libs are allocated on the EAR, not on the EJB. This is only for runtime, for compilation you must reference the hibernate jar with an external jar file, as always.
A dirty solution could be this one: open your generated EAR with de-compressor, and copy your hibernate jar on it (at root). This way you'll load hibernate classes at runtime (I know this is an horrible solution, this is only for testing).
As I said before, I'm not used to DCs, so this could be wrong, and be a waste of time... I don't know further...
Good luck
Eneko.

Med Rec medrec tutorial 10 deployments-- EJB Modules EJB is not shown

This note adds missing steps in the Med Rec (medrec) Tutorial 10
The tutorial shows how to use EJBGEN to generate EJB classes (incl java source) from .ejb files.
Unfortunately it is missing a few key details. These are described below.
Many thanks to Chris Wall for supplying the answers and hints.
Q: The tutorial includes deploying the manually generated physSessionEjb’s. After doing the step that generates the PhysSession*.java files, onefinds that when trying to deploy that there are no class files – nothing has been built. Are the class files supposed to be generated by the ejbgen step?
[Chris] No, EJBGen just generates the local and remote interfaces and descriptors only. An additional step should be added to explain how to build the newly generated EJBs. I believe you are correct in calling “src/physicianEar$ ant –f build.xml build”.
Q: Manually built the class files using ‘ant –f build.xml build’ in the physicianEar src dir – but that failed in the acc.split.dir step with class not found /org/apache/struts/action/ActionForm.
Obviously did not get the struts jars on the classpath. But as much of the build as completed did include creating the class files.
[Chris] Yes, it looks like struts.jar is not in the classpath. Is this the “build.split.dir” or “appc.split.dir” target? In either case, wlcompile and wlappc should recognized all libs in "${app-inf.dest.lib}" and append them to the compile/appc classpath automatically. The libs should have been copied during the “prepare” target. Can you make sure that struts.jar exists in c:/medrec_tutorial/build/physicianEar/APP-INF/lib? If not, re-run the target with verbose: “src/physicianEar$ ant -verbose -f build.xml build”, and make sure that the libs are copied in the “prepare” target.
Q: When doing the deploy step, we get no errors but on the console window and do not see the tutorial_deployment item under DeploymentsàEJB Modules. There is something under Deployments-->Applications --> tutorial_deployment. It appears the deploy failed since there’s nothing under Deployments --> EJB Modules, and what is there is ‘left over’ from deploying the jar (the ear?) that contains the stuff deployed by the deploy step at the start of tutorial 10.
[Chris] Once the build is successful, you must deploy the EAR. This is done by executing : “src/physicianEar$ ant -f build.xml redeploy.physician.ear”. Again, a step that was left out. Yes, you should be looking at Deployments--> Applications--> tutorial_deployment. So, to summarize: generated the local and remote and descriptors for the EJB, compile the EJB and package the EAR, deploy the EAR, and then view the deployment in the console.

This note adds missing steps in the Med Rec (medrec) Tutorial 10
The tutorial shows how to use EJBGEN to generate EJB classes (incl java source) from .ejb files.
Unfortunately it is missing a few key details. These are described below.
Many thanks to Chris Wall for supplying the answers and hints.
Q: The tutorial includes deploying the manually generated physSessionEjb’s. After doing the step that generates the PhysSession*.java files, onefinds that when trying to deploy that there are no class files – nothing has been built. Are the class files supposed to be generated by the ejbgen step?
[Chris] No, EJBGen just generates the local and remote interfaces and descriptors only. An additional step should be added to explain how to build the newly generated EJBs. I believe you are correct in calling “src/physicianEar$ ant –f build.xml build”.
Q: Manually built the class files using ‘ant –f build.xml build’ in the physicianEar src dir – but that failed in the acc.split.dir step with class not found /org/apache/struts/action/ActionForm.
Obviously did not get the struts jars on the classpath. But as much of the build as completed did include creating the class files.
[Chris] Yes, it looks like struts.jar is not in the classpath. Is this the “build.split.dir” or “appc.split.dir” target? In either case, wlcompile and wlappc should recognized all libs in "${app-inf.dest.lib}" and append them to the compile/appc classpath automatically. The libs should have been copied during the “prepare” target. Can you make sure that struts.jar exists in c:/medrec_tutorial/build/physicianEar/APP-INF/lib? If not, re-run the target with verbose: “src/physicianEar$ ant -verbose -f build.xml build”, and make sure that the libs are copied in the “prepare” target.
Q: When doing the deploy step, we get no errors but on the console window and do not see the tutorial_deployment item under DeploymentsàEJB Modules. There is something under Deployments-->Applications --> tutorial_deployment. It appears the deploy failed since there’s nothing under Deployments --> EJB Modules, and what is there is ‘left over’ from deploying the jar (the ear?) that contains the stuff deployed by the deploy step at the start of tutorial 10.
[Chris] Once the build is successful, you must deploy the EAR. This is done by executing : “src/physicianEar$ ant -f build.xml redeploy.physician.ear”. Again, a step that was left out. Yes, you should be looking at Deployments--> Applications--> tutorial_deployment. So, to summarize: generated the local and remote and descriptors for the EJB, compile the EJB and package the EAR, deploy the EAR, and then view the deployment in the console.

Defining cmp-relation to EB contained in different ejb module project

Hello,
I have to migrate an existing J2EE Application to SAP NetWeaver and WebAS. My task is to keep the structure as similar as possible to increase the recognition factor although using Developer Studio as IDE.
In this application there are cmp relations defined that reference EntityBeans from other sub projects (that I tried to create in different ejb module projects).
References in the same ejb module project seem to work fine but I cannot select referenced EntityBeans of other projects as relation target.
Another remark:
In the given application the ejb-jar.xml-file of the referencing component contains entries of the referenced one. The Developer Studio allows to Add EJBs to ejb-jar.xml, even referenced Beans. But when I select to add referenced EJBs only the Beans of the current project can be chosen. (I did not forget to enter an ejb-local-ref from the referencing to the referenced Bean in ejb-jar.xml as well)
Can anyone give me a hint on how to solve this task? Or where I have forgotten to add a reference?
Thanks
Daniel

Hello Viliana,
Hello everybody else!
I'm currently writing the corresponding masterthesis to my project. That's why I have to deal with this "problem" again.
I tried to look up the part of the spec Viliana's hint ("When you create and use cmp-relationships your beans must be included in one and the same JAR file (that's according to the EJB specification)") bases on.
But the only thing I found addressing this issue tells something else:
"[...]Container-managed relationships can exist only among entity beans within the same local relationship
scope,[...]" (EJBSpec2.1, section 10.3.2)
In my opinion this does not necessarily mean that they have to be in the same JAR but in the same EAR file...
This would mean, that the chosen cmp-relationships strategy with ejb-module-projects is too restrictive.
Can anyone help me with this... Does anyone know further hints on how Entity Beans have to be deployed when belonging to cmp-relationships?
Thanks a lot for any hint on this
Best regards,
Daniel

File splitting in EJB module

Hi,
I have a EJB module (used in sender file adapter) which takes a flat file as input and then splits the file into multiple files(XML) which needs to be sent to the Integration Engine.
Is there any method by which I can return multiple XMLs from the same EJB module to the Integration Engine.
Will writing the return statement from the EJB in a loop do the job?
Thanks,
Shiladitya

Hi Shiladitya !
Multiple EJB module outputs for the file adapter is not possible. If you need splitting, maybe you could use an external application that does the job and then the XI scenarios picks up the XML files (use the filename to get them in order), or maybe you could "split" your original scenario in 2 scenarios. One scenario, to split the file : File-XI-File and the other one to process the result of the first one : File-XI-Target Adapter.
In the first scenario you could use the "recordsets per message" parameter of the file adapter sender comm channel, to automatically split the source file in several XML messages.
Why do you need an EJB module ?
Regards,
Matias.

No ejb-j2ee-engine.xml after new EJB module project

Hi! Can someone please help. Newbie here
I installed SDK 1.4.2_13
I installed Netweaver Developer Studio 7.0.09
When I create a new ejb module project I only see the files
ejb-jar.xml
ejbmodule
I miss the file ejb-j2ee-engine.xml
How is this possible?

I solved the problem by uninstalling SAP Netweaver Developer Studio version 7.0.09 and install version 7.0.08
However, It's still strange why there was no ejb-j2ee-engine.xml when there was created a new EJB project module.

Share persistence.xml file between two EJB modules in EAR

Hello, everybody!
First of all, I would like to say that I already posted this question in another forum:
[http://community.jboss.org/thread/154128?tstart=0]
But as I haven't got any answer from there and this issue is very crucial to me I'm posting it here too in the hope that I get an answer. So, here it goes:
I have two EJB modules in an EAR module. I would like to know how to share a single persistence.xml file with these two EJB modules. If I replicate the persistence.xml file in the two EJB modules, the EAR project deploys ok, but of course that's not what we want. If I remove the persistence.xml file from any of the EJB projects, the EAR doesn't deploy properly. I'm stuck with this. I've already tried many kind of configurations but none worked. I really would like to have some help with this issue to proceed working. This is my EAR structure:
solicitacoes-ejb.jar (EJB session beans)
solicitacoes-dao.jar (EJB interfaces)
solicitacoes-dao-jpa.jar (EJB session beans)
solicitacoes-ejbClient.jar (entities and EJB interfaces)
solicitacoes-web.war
META-INF/This is my application.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd"
version="5">
 <display-name>solicitacoes-ear</display-name>
 <module>
 <ejb>solicitacoes-ejb.jar</ejb>
 </module>
 <module>
 <ejb>solicitacoes-dao-jpa.jar</ejb>
 </module>
 <module>
 <web>
 <web-uri>solicitacoes-web.war</web-uri>
 <context-root>solicitacoes</context-root>
 </web>
 </module>
</application>If I remove the persistence.xml file from one of the EJB modules, let's say solicitacoes-dao-jpa.jar, I get this error when deploying the EAR file:
... 39 more
Caused by: java.lang.IllegalArgumentException: Can't find a persistence unit named 'null' in AbstractVFSDeploymentContext@28359170{vfs:///C:/jboss-6.0.0.20100429-M3/server/default/deploy/solicitacoes-ear.ear/solicitacoes-dao-jpa.jar/}
at org.jboss.jpa.resolvers.BasePersistenceUnitDependencyResolver.resolvePersistenceUnitSupplier(BasePersistenceUnitDependencyResolver.java:107) [:1.0.2-alpha-1]
at org.jboss.ejb3.Ejb3Deployment.resolvePersistenceUnitSupplier(Ejb3Deployment.java:778) [:1.3.1]
at org.jboss.ejb3.EJBContainer.resolvePersistenceUnitSupplier(EJBContainer.java:1517) [:1.3.1]
at org.jboss.injection.PersistenceUnitHandler.addPUDependency(PersistenceUnitHandler.java:130) [:1.3.1]
... 43 moreI need help with this issue. As you could see, the EJB container doesn't like to see an EJB module without a persistence.xml file. This is clearly a dumb decision though. I agree with it if there was only one EJB module in an EAR. But the container should have been smart enough to require only one persistence.xml file in an EAR module with more than one EJB module, and share that persistece context with the whole EAR.
Acting the way it is acting now, the container forces us to duplicate the persistece.xml file and kill our application modularity. This is clearly wrong. I've already tried to put the entity classes and persistence.xml file in the lib directory of the EAR, but it didn't work either. The container needs to have the persistence.xml file in both EJB modules.
I don't know if this is a JBoss implementation decision or if it comes from the Java EE 6 specification. Whatever it is, it goes against all good modular and good design decision. Please if some of you know how to solve this, took a little time to tell me how. I would be very grateful.
Thank you in advance.
Marcos

Dear Mr. gimbal2,
In another occasion I would not reply to such a 'helpful' answer like the one you gave me (yes, it is undoubtedly an answer because that's how you classified it in the beginning of your reply), but as today I have plenty of time here in my job, for this week we're not working full time as usual, I decided to reply to it.
You have to completely overhaul your attitude.I really didn't know I was taking so personal on this issue to have to 'completely overhaul my attitude'. Thank you for pointing that out.
In stead of calling the technology dumb, admit to yourself that perhaps you don't understand it properly and that your ideas of what is correct design perhaps is a little lacking. I didn't call the technology dumb because I stated very clearly that I don't know for sure if it is working this way. I said in the last paragraph:
+"I don't know if this is a JBoss implementation decision or if it comes from the Java EE 6 specification. Whatever it is, it goes against all good modular and good design decision."+
So, I let implicit the fact that the technology or the implementation of the technology is dumb only if it doesn't allow this possibility. Regarding the fact that your said that I should
admit to myself that perhaps I don't understand it properly, where did I stated in my question that I understand it completely? It's clear in the last paragraph that I don't. If I'm asking that's because I have doubts. Maybe my ideas of what is correct is wrong, and that's why I'm here in this forum. But everyone with a good sense knows that what I propose in this discussion is by no means a wrong design decision. Where is it a sin to have more than one EJB module in a EAR and a persisntece.xml file shared for the whole EAR? Does everyone that has more than one EJB module in an EAR module need to connect to more than one database? Is it wrong to want to have your DAO implementation in a separate EJB module in order to make deployment easy and also changes, if you later want to replace that implementation with another one without affecting
the other modules? I don't think that a design decision that seeks this is lacking. I don't think that Java EE today is a dumb technoloby, but everyone knows that before it gets to the present level, it was a technology known to have made big dumb decisions that the community latter corrected, with ideas like O/R mapping (Hibernate), dependency injection (Spring), Struts and lots of other examples that we all know. No one can deny this and lots of wrong things will continue to be fixed in later releases.
Maybe when you rise yourself back to that level, you open yourself up again to thinking in correct solutions in stead of trying to hammer through your own poorly chosen one.To be sincere, I see you took very personal about this issue. You really shows to be someone that has no respect to other people and you judge them too. I must say that I got surprised by the way you answered my post. I didn't expect to get such sarcastic answer to what I asked. I personally don't act this way. If I can't help a person, I also don't try to ridicularize him.
Marcos

How does servicegen choose EJBs to generate webservices?

I'd like to know how servicegen Ant task chooses the EJBs to generate webservice operations from. In one of my sample applications the ejbgen Ant task (com.bea.wls.ejbgen.ant.EJBGenAntTask) generates stateless session beans. Servicegen then generates webservice operations for each of the public methods defined in the stateless session beans.
If a similar session bean is generated using XDoclet (xdoclet.modules.ejb.EjbDocletTask) instead of "ejbgen", servicegen does not find any operation to create webservices from! The <operations>-Element in the generated web-services.xml is empty (see error message below).
Are there any naming conventions a generator of EJB-Code should follow if the generated JAR file is used as input for servicegen afterwards?
<servicegen
<service
ejbJar="${build}/${ejb_jar_file}"
>
</service>
</servicegen>
weblogic.webservice.dd.DDProcessingException: There must be at least one <operation> element in <operations> (Line 14, Column 8)
at weblogic.webservice.dd.DDLoader.processOperationElements(DDLoader.java:1000)
at weblogic.webservice.dd.DDLoader.processOperationsElement(DDLoader.java:986)
at weblogic.webservice.dd.DDLoader.processWebServiceElement(DDLoader.java:497)
at weblogic.webservice.dd.DDLoader.processWebServiceElements(DDLoader.java:310)
at weblogic.webservice.dd.DDLoader.processWebServicesElement(DDLoader.java:298)
at weblogic.webservice.dd.DDLoader.load(DDLoader.java:276)
at weblogic.webservice.util.WebServiceWarFile.getWSDD(WebServiceWarFile.java:86)
at weblogic.webservice.tools.build.internal.WSDLGenImpl.getWebServiceMBean(WSDLGenImpl.java:194)
at weblogic.webservice.tools.build.internal.WSDLGenImpl.run(WSDLGenImpl.java:133)
at weblogic.webservice.tools.build.internal.ClientGenImpl.doClientGenFromEAR(ClientGenImpl.java:438)
at weblogic.webservice.tools.build.internal.ClientGenImpl.run(ClientGenImpl.java:345)
at weblogic.ant.taskdefs.webservices.servicegen.ServiceGenTask.generateClient(ServiceGenTask.java:597)
at weblogic.ant.taskdefs.webservices.servicegen.ServiceGenTask.execute(ServiceGenTask.java:195)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
at org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:385)
at org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:136)

Hi lerppu
I got same error messages. could you please post how you have solved this problem. i'm a student and is pretty new to j2ee projects. you help would be appreciated.
thanks in advance.

Not able to update single file in a non ejb Module related jar

Hey all,
I have depoyed my j2ee application .ear on NW webAS .
 This application apart from having all the ejb Modules related jar, also has a jar which has all my properties files being accessed by my application.
Very often is it required by me to update these files and restart the application. However i couldnot find a way to update these single files.
When i select by deployed application.ear and click Single File Update feature provided by SAP in visual Admin, it shown only ejb modulerelated jar. It dosent show my jar containing properties file.
I have to redeploy my application again everytime i change a small properties file.
Please let me if there is a way to update these sngle files

Hi,
>
Vikram D Salvi wrote:
> MOVE-CORRESPONDING ZSTRUC_CM TO I_TAB. not working
>
> UPDATE ZTEST_CM FROM ZSTRUC_CM. not working
Instead of the move statement you need to use the append work area to internal table statement. you need to have the same structure for the work area and the internal tbale.
Then use the modify data base table from internal table statement.
Regards
Ansari

How to add a library jar to a EJB module?

Hi All,
in J2EE the normal procedure to a library jar to a module, is to add the library in the Class-Path header of the manifest of the module, and then include the actual jar in the root structure of the ear file. Unfortunately it is not clear to me how S1S5 update 1 supports this. The only option Studio I found so far, is to add the jar as a 'file to include', but then the contents is added to the module jar and not to the ear file itself, resulting in duplication of classes across modules. Is there an option to add the library jar in the Class-Path of the module?
Thanks in advance,
Stijn

I believe that better support for this was added in the Sun Java Studio 6 EA release. It was added to the Extra Files property on an EJB Module.

Converting existing ejb module project into DC

Hi,
1. I have created a local Ejb Module Project
2. Also a web service is created using that ejb(stateless) && deployed on the server.
3. I want to convert this local ejb module project into DC
4. I have copied everything from local ejb module project(eg.ejb,classes,virtual Interface & web service dif etc) & pasted in the DC structure.
5. While creating web service, it shows me a deployment error, regarding web service name (which is already exists).
6. I can create web service with different name & it works fine,
but I don't want to use different name for web service.
7. Is it possible to again create web service with the same name?
8. Or is there another way for doing this?
Best regards,
Nilesh

Have you tried to undeploy the old project? This should work out.
\-- Vladimir

Error targeting server for the EJB module while deploying the sample banking application

I am currently having a very difficult time attempting to deploy the
example banking application that I downloaded from the BEA website. I
have followed all of the steps in the "Hands On: Deploying the Sample
Banking Application" document, and I do fine until I get to the next to
last step. When I attempt to target the server for the EJB module, the
deployment process generates the error that I have included at the end
of this message.
I can get to the login.html page under "http://localhost:7001/banking/",
but after that I can't go further.
Any suggestions. BTW, in case you haven't figured it out, I'm brand new
to BEA WebLogic server.
Thanks in advance for any help you can offer.
Scott
Error deploying application \ejb:
Unable to deploy EJB: \ejb from \ejb:
Compiler failed
executable.exec(java.lang.String[javac,-nowarn,-classpath,E:\bea\wlserver6.1\tmp_ejbwinged-demon7001\banking-exploded_\ejb;E:\bea\wlserver6.1\.\config\ScottsServer\applications\.wlnotdelete\wlap60763\ejb;E:\bea\jdk131\jre\lib\rt.jar;E:\bea\jdk131\jre\lib\i18n.jar;E:\bea\jdk131\jre\lib\sunrsasign.jar;E:\bea\jdk131\jre\classes;.;E:\bea\wlserver6.1\lib\weblogic_sp.jar;E:\bea\wlserver6.1\lib\weblogic.jar,-d,E:\bea\wlserver6.1\tmp_ejbwinged-demon7001\banking-exploded_\ejb,E:\bea\wlserver6.1\tmp_ejbwinged-demon7001\banking-exploded_\ejb\examples\tutorials\migration\banking\*.java])
at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:302)
at weblogic.ejb20.deployer.Deployer.runEJBC(Deployer.java:296)
at weblogic.ejb20.deployer.Deployer.compileEJB(Deployer.java:684)
at weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:851)
at weblogic.j2ee.EJBComponent.deploy(EJBComponent.java:30)
at weblogic.j2ee.Application.addComponent(Application.java:163)
at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:117)
at
weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:329)
at
weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:144)
at java.lang.reflect.Method.invoke(Native Method)
at
weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636)
at
weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621)
at
weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:359)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at
weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(ConfigurationMBeanImpl.java:491)
at
weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:361)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:468)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:209)
at $Proxy11.addDeployment(Unknown Source)
at
weblogic.management.internal.DynamicMBeanImpl.updateDeployments(DynamicMBeanImpl.java:1516)
at
weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:895)
at
weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:847)
at
weblogic.management.internal.ConfigurationMBeanImpl.setAttribute(ConfigurationMBeanImpl.java:295)
at
com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1356)
at
com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1331)
at weblogic.management.internal.MBeanProxy.setAttribute(MBeanProxy.java:322)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:204)
at $Proxy68.setTargets(Unknown Source)
at java.lang.reflect.Method.invoke(Native Method)
at
weblogic.management.console.info.FilteredMBeanAttribute.doSet(FilteredMBeanAttribute.java:92)
at
weblogic.management.console.actions.mbean.DoEditMBeanAction.perform(DoEditMBeanAction.java:135)
at
weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:171)
at
weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
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.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

The deployment process invokes javac internally to compile some generated classes.
Do you have javac installed and in the path?
Seth
Scott Springer wrote:
I am currently having a very difficult time attempting to deploy the
example banking application that I downloaded from the BEA website. I
have followed all of the steps in the "Hands On: Deploying the Sample
Banking Application" document, and I do fine until I get to the next to
last step. When I attempt to target the server for the EJB module, the
deployment process generates the error that I have included at the end
of this message.
I can get to the login.html page under "http://localhost:7001/banking/",
but after that I can't go further.
Any suggestions. BTW, in case you haven't figured it out, I'm brand new
to BEA WebLogic server.
Thanks in advance for any help you can offer.
Scott
Error deploying application \ejb:
Unable to deploy EJB: \ejb from \ejb:
Compiler failed
executable.exec(java.lang.String[javac,-nowarn,-classpath,E:\bea\wlserver6.1\tmp_ejbwinged-demon7001\banking-exploded_\ejb;E:\bea\wlserver6.1\.\config\ScottsServer\applications\.wlnotdelete\wlap60763\ejb;E:\bea\jdk131\jre\lib\rt.jar;E:\bea\jdk131\jre\lib\i18n.jar;E:\bea\jdk131\jre\lib\sunrsasign.jar;E:\bea\jdk131\jre\classes;.;E:\bea\wlserver6.1\lib\weblogic_sp.jar;E:\bea\wlserver6.1\lib\weblogic.jar,-d,E:\bea\wlserver6.1\tmp_ejbwinged-demon7001\banking-exploded_\ejb,E:\bea\wlserver6.1\tmp_ejbwinged-demon7001\banking-exploded_\ejb\examples\tutorials\migration\banking\*.java])
at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:302)
at weblogic.ejb20.deployer.Deployer.runEJBC(Deployer.java:296)
at weblogic.ejb20.deployer.Deployer.compileEJB(Deployer.java:684)
at weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:851)
at weblogic.j2ee.EJBComponent.deploy(EJBComponent.java:30)
at weblogic.j2ee.Application.addComponent(Application.java:163)
at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:117)
at
weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:329)
at
weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:144)
at java.lang.reflect.Method.invoke(Native Method)
at
weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636)
at
weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621)
at
weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:359)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at
weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(ConfigurationMBeanImpl.java:491)
at
weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:361)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:468)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:209)
at $Proxy11.addDeployment(Unknown Source)
at
weblogic.management.internal.DynamicMBeanImpl.updateDeployments(DynamicMBeanImpl.java:1516)
at
weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:895)
at
weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:847)
at
weblogic.management.internal.ConfigurationMBeanImpl.setAttribute(ConfigurationMBeanImpl.java:295)
at
com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1356)
at
com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1331)
at weblogic.management.internal.MBeanProxy.setAttribute(MBeanProxy.java:322)
at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:204)
at $Proxy68.setTargets(Unknown Source)
at java.lang.reflect.Method.invoke(Native Method)
at
weblogic.management.console.info.FilteredMBeanAttribute.doSet(FilteredMBeanAttribute.java:92)
at
weblogic.management.console.actions.mbean.DoEditMBeanAction.perform(DoEditMBeanAction.java:135)
at
weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:171)
at
weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
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.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

Lack of modularity in Projects for EJB module

Problem
For a project you have many enterprise bean components. In JDeveloper, currently, all the information like persistence-type,
resource-reference, etc reside in the ejb-jar.xml which is project specific.
(1) In the real-world, developers work on different modules with small individual work spaces with a small number of
enterprise components and web compoents with a CVS system to manage version of the source code
(2) The developer works on the source and check it in the CVS repository
(3) A packager will take components from the CVS repository and make a build for a customer according to the order
(Build-to-Order approach)
(4) In JDeveloper he might have to make the ejb-jar.xml again which is very cumbersome and timeconsuming
Suggestion
(1) The current system of maintaining ejb-jar.xml in the project is OK
(2) But the information in the ejb-jar xml ABOUT EACH EJB COMPONENT should also be maintained at the EJB component level like
a small ejb-jar.xml file specific to the one and only one component.
(3) Whenever the EJB component id edited, this modular ejb-jar.xml file will be edited too.
(4) Later while making the main ejb-jar xml for deployment, the info in these small modular xml files will be read, the main
project level ejb-jar xml will be prepared.
(5) The main project level ejb-jar.xml can also be prepared when the project is rebuilt (clean/force compile) and all te
small modular files are updated.
With regards
Amit

Hello,
Yes we do read every OTN message, though we often have some internal discussion before we post a reply.
In your specific situation, you could just break up the EJBs into different projects:
- Each EJB module in a separate project.
- Each EJB project builds a separate EJB JAR.
- When assembling the EAR, pull in as many EJB JAR files as necessary to support the WAR and other pieces.
JDeveloper already has support for the above setup. Starting with JDev 9.0.3, you can also establish dependencies between projects to make the classes built by one project visible to another project's classpath.
For us to implement a complete solution where small ejb-jar.xml files are merged into one large ejb-jar.xml file, we'd like to understand how you'd go about resolving conflicts in elements being merged:
- conflicting <method-permission>
- conflicting <container-transaction>
- conflicting <relationship-role>
- conflicting <env-entry>
- ... a number of other potential conflicts ...
We could do automatic merges when there are no conflicts. For the situations where there are conflicts, can you describe some solutions that you would consider acceptable?

Why is there no EJB modules generated in chapter 10 of Medrec Tutorial?

Similar Messages

Maybe you are looking for