I have jbossesb-server-4.11 and eclipse-jee-juno.
I want to create some simple EJB application, deploy it on server and call some method from client. Everything seems to be clear.
I have found a simple Hello world application here: https://sites.google.com/a/thedevinfo.com/thedevinfo/Home/jboss/jboss-application-server/ejb3-session-bean-tutorial-using-jboss-and-eclipse.
I did all the same, I also tried to download this example from this site but it does not work for me.
I created JBoss server in Eclipse, then I run my ejb application on this server, then I tryied to get my bean this way:
InitialContext ctx = new InitialContext(props);
MyBeanRemote bean = (MyBeanRemote) ctx.lookup("MyBean/remote");
But i have the following error: "javax.naming.NameNotFoundException: MyBean not bound".
Here is my simple code in ejb project:
#Remote
public interface MyBeanRemote extends IMyBean{}
#Local
public interface MyBeanLocal extends IMyBean {}
#Stateless
public class MyBean implements MyBeanLocal, MyBeanRemote {
public void doSomething() {
System.out.println("Hello World!");
}
}
Please advice me where I am wrong?
It looks like standalone jbossesb-server is very narrowly specialized product. It provides ESB-specific functionality but lacks EJB support.
Your test app deploys and runs fine on vanilla JBossAS 4.2.3.GA though (AS 4.2.3 is the foundation for jbossesb-server-4.11 I think).
If ESB is a must for you, I recommend installing JBoss ESB as an extension for plain JBoss 4.2.3.GA or maybe newer 5.x, 6.x series (AFAIK 7.x is not supported yet). In order to do so you need to download jboss-4.2.3.GA and jbossesb-4.11.zip instead of jbossesb-server-4.11.zip. Then you need to follow this instructions.
Pay attention there are two editions of JBossAS 4.2.3:
jboss-4.2.3.GA.zip - for JDK5
jboss-4.2.3.GA-jdk6.zip - for JDK6+
the same is true for 5.x series (6.x and 7.x require JDK6+).
The other option is using full commercial SOA solution: RedHat's SOA Platform. It's not cheap though.
Related
I built a simple Java web application. It provides a series of RESTful APIs for the user to carry out certain operations on a Java DB through a web interface. I used NetBeans environment during the development, and Glassfish for testing.
Now that I finished it, I would like to be able to deploy it on another machine using binaries (although as for now I use the same machine until I learn how to do it).
I installed Tomcat 7, and moved the .war file into Tomcat's webapp folder. The application deploys. Thereafter I try to read some data from the databse using a button I created just for this, but get the following error
I am not sure what went wrong, but I have two theories.
1) The web application cannot connect to the database. Yet when I attempted to run the application again, after starting JavaDB from NetBeans, there was no difference.
2) Somehow, the application cannot reach the Node service. I assumed that there will be no need to change the API links while moving the app, but perhaps I was wrong.
Or maybe there is some other issue I did not consider? I will be grateful for any advice about how to properly deploy such an application.
EDIT: The issue was solved by using TomEE.
The error is come from your application server of choice.
TomCat is only a servlet container (means it only support Servlet/JSP).
Any other feature (JAX-RS, CDI etc) require a Java EE certified server e.g. GlassFish, WildFly,Payara, WebLogic, OpenLiberty or TomEE.
TomEE could be your best bet if you want to use TomCat in your production or test environment, it is basically TomCat + Java EE other feature.
EDIT:
TomEE don't have a GUI for JNDI datasource configuration like GlassFish, you need to edit conf/tomee.xml
<Resource id="myDataSource" type="javax.sql.DataSource">
jdbcDriver = org.apache.derby.jdbc.ClientDriver
jdbcUrl = jdbc:derby://localhost:1527/dbname
userName = app
password = app
</Resource>
And in your java code:
#Path("resources")
#Stateless
public class MyResources{
#Resource(name="myDataSource")
DataSource dataSource;
#GET
public Response SomeMethod(){
//Do stuff here
}
}
You can check here for more detail configuration on data source.
I am a little new to J2EE. I have a EJB3 project and I want to run a class on application start-up, how can I do that?
I know in EJB3.1 I can use #startup and #singleton unfortunately that is not a option and I have to use EJb3 and java 5. I have done some research and there were a few solutions but I have been unable to make it work.
WebSphere Application Server version 6.1 does not support EJB3 with a standard installation. You also need to have a feature pack for EJB 3.0 installed.
See this information on the IBM site.
If this is not your issue you should update your question with more detail of what goes wrong.
Your only options prior to WebSphere 8 (with EJB 3.1 support) are:
WebSphere startup beans. These are a programming model extension
Package a WAR with the application, and use a ServletContextListener to initialize state used by the EJBs.
I am using EJB3.0. I have an application running on websphere app server v7 who is executing a remote ejb 3.0 running in a different application on the same app server.
I use #EJB annotation to inject remote interface in my code. It runs fine, so I am sure all configuration and code is ok.
When the other application (containing the ejb) is restarted (it may be deployed because of a fix elsewhere in the code) my application and its client does not run anymore, it seems to lose the reference of the ejb stub.
I can fix the problem simply restarting my application, but it is not a good practice in our production environment.
I would like to re-inject or renew the ejb if needed. Is it possible?
Another way should be creating ejb stubs and adding them to my application (not a good thing anyway, I would avoid it).
I also tried to switch to the old 'lookup' way through InitialContext but only get a ClassCastException on stubs... again, it seems to need concrete stubs again...
Is there a simple solution to this 'classic' scenario?
Thank you
MMad
I remember seeing such problems in earlier WebSphere 7 versions, but they were fixed in more recent versions. You should install the latest fix pack for 7.0, and if the problem still persists, open a PMR with IBM.
Chapter 126 of the OSGI Enterprise Release 5 specification mentions compatibility:
"Support the traditional JNDI programming model used by Java SE and Java EE clients."
and use of OSGI-unaware code:
"Clients and JNDI Context providers that are unaware of OSGi use static methods to connect to the
JRE JNDI implementation. The InitialContext class provides access to a Context from a provider and
providers use the static NamingManager methods to do object conversion and find URL Contexts.
This traditional model is not aware of OSGi and can therefore only be used reliably if the consequences
of this lack of OSGi awareness are managed."
but it is not clear to me if this text only applies to "legacy" code executed inside an OSGI bundle, or also to code outside the OSGI container, f ex in a scenario where the OSGI container is embedded in an application.
In an embedding scenario, there may be application code both outside and inside the OSGI container that performs JNDI calls, and as they execute in the same JVM they will share JNDI implementation.
Question: Should an OSGI JNDI implementation running in an embedded OSGI container allow OSGI-unaware code outside the container to perform its JNDI calls like usual, or is some porting to "OSGI-awareness" required?
Trying this out myself with Apache Karaf 2.3.0 (which uses Apache Aries JNDI 1.0.0) this doesn't seem to work, as Apache Aries requires JNDI client calls to originate from an OSGI bundle.
Partial stacktrace:
javax.naming.NoInitialContextException: The calling code's BundleContext could not be determined.
at org.apache.aries.jndi.OSGiInitialContextFactoryBuilder.getInitialContext(OSGiInitialContextFactoryBuilder.java:46)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.<init>(InitialContext.java:192)
Question: Is this correct behaviour, or is there a section of the specification I can refer to that is violated by this limitation?
I ran into same issue when trying to deploy Apache Karaf on Weblogic.
We use karaf through a servlet bridge - a war is deployed in weblogic which bridges all http requests to karaf.
I am running with the the following applications on weblogic:
app1 (uses JNDI)
app2
karaf-bridge (bridges requests to Karaf)
As soon as karaf starts the Aries JNDI implementation running inside Karaf sets InitialContextFactoryBuilder inside javax.naming.NamingManager to its own implementation. NamingManager holds a static reference to the initial context factory builder, so whichever implementation, irrespective of whether its running in an OSGI environment, sets this static reference becomes the JNDI provider.
In my case when app1 (non-OSGI) tries to do a new InitialContext, Aries JNDI tries to resolve it using the BundleContext and fails.
I fixed this using some very ugly hacks that involved extracting the javax.naming package from jre and installing it as a bundle in karaf.
So the answer to your question: I think the issue is really in the jre and not with OSGI on how JNDI lookup is managed.
I'm not sure if I understand the problem correctly... JNDI is a Service Provider Interface, and it needs some underlying implementation to run with. All you need to do is to provision it the OSGI container.
I would recommend creating single bundle with all jars needed by JNDI and export all packages. Then use Dynamic-Import: * to use it. It worked in our case (Eclipse RCP application with JBoss 5 JNDI used for EJB calls).
However if you need JNDI inside and outside of the container and you don't want to struggle with Classloading, I would recommend adding all jars to the applications classpath. This way it should be accessible in whole your application.
Apache Aries seems to have thought about this and have provided an implementation of JRE initial context factory builder (org.apache.aries.jndi.JREInitialContextFactoryBuilder) which seems to work. However, for this to work, I had to change Aries code that registers the JVM wide initial context factory builder. There may be another (and possibly better) way of achieving this. But this seemed to work.
Also, note that the problem does not stop at InitialContextFactoryBuilder being set in NamingManager. The same issue arises for ObjectFactoryBuilder (which is again set JVM wide in NamingManager). Depending on the JNDI provider you are trying to connect to, you may need to change that part of Aries JNDI code as well. e.g. for Tibco EMS JNDI connection, I had to tweak the code for OSGiObjectFactoryBuilder from Aries to return a Tibco specific ObjectFactory. This can be easily generalized using Context.OBJECT_FACTORIES environment value.
I've raised a JIRA for the same - https://issues.apache.org/jira/browse/ARIES-1127
I am trying to deploy a spring message message driven POJO on weblogic 8.1. It is a simple POJO, and it works fine being run outside of an application server, but the messages do not seem to be picked up at all. I have created empty home and remote interfaces, as well as a container bean class that contains an instance of the pojo which it gets from the application context. I then added this container bean class to the ejb-jar.xml as a . I have not been able to get the messages pick up.
Does anyone have any suggestions as to what I am doing wrong? Could anyone point me to a tutorial on how to deploy a MDP?
Thanks.
Here's a tutorial:
http://java-x.blogspot.com/2006/12/implementing-jms-with-spring-message.html
I have no idea what you're talking about when you say "home and remote interfaces". You said Spring POJO, but home and remote interfaces are EJB 2.0 artifacts.
The important question to answer is: Are your message driven component EJBs (MDB) or Spring POJO (MDP)? If they're EJBs, I totally understand why you need home and remote interfaces. If not, I would say this could be a pure web app, packaged in a WAR, without the EJB XML.
You also need a JMS queue to be set up. Have you done that properly? WebLogic 8.1 means JMS 1.0.2.
That's an OLD version of WebLogic and JDK. Why aren't you using WebLogic 10 and JDK 6?