It seems like some class didn't unload properly from the JVM. This tends to happen a
lot with Struts but it also happens with anything that the JVM understands to be still
in use - that is; an active instance of the class remains in use in the JVM.
For your issue, you might be able to get around
If nothing else, the advantage is EJB 2.0 and EJB-QL over EJB 1.1, particularly with
entity bean development. At least, I think this is still the case as it has been a
long time since I've used 2.4.x.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3832238#3832
It doesn't look like it is binding correctly to the interface. It should look like
this:
2004-04-24 13:25:06,734 INFO [org.jboss.naming.NamingService] Starting jnp server
| 2004-04-24 13:25:06,886 INFO [org.jboss.naming.NamingService] Started
jnpPort=1099, rmiPort=1098, backlog=50, bindAddres
The *-service.xml is no longer used to define datasource configurations. The 3.2.x
release uses *-ds.xml. The configuration is different in JBoss 3.2.x.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3832208#3832208
Reply to the post :
http://www.jboss.org/in
Make sure that your Red Hat system has its iptables (or ipchains depending on how it
has been set up) configuration such that it allows connection from external systems.
Are you able to telnet to port 1099 on the server with JBoss running on it?
View the original post :
http://www.jboss.org/ind
Rendering is a little more difficult with JDK 1.3.x on Linux/Unix - you need an
operating X server, or have JPA or xvfb. Getting running on JBoss 3.2.x with JDK 1.4.x
should allow you to move forward without these contortions. Sure you still need the
X11 libraries.
MHO.
View the original post
You are probably using the old datasource definition files from 3.0.x in 3.2.x. This
won't work as the configuration has been simplified in JBoss 3.2.x and are of a
different format. Get the appropriate datasource example file for your database from
JBOSS_HOME/docs/examples/jca of the JBoss 3.2.
Try the following XDoclet snippet:
* @ejb.resource-ref res-auth="Application"
| * res-name="jdbc/FooDS"
| * res-type="javax.sql.DataSource"
| * @jboss.resource-ref res-ref-name="jdbc/FooDS"
| * jndi-name="java:/FooDS"
The JNDI binding for your datasource is "java:/FooDS" as given by the JN
A cron job specifically cleans up the /tmp directory. It doesn't clean up the /jetty
directory.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3831512#3831512
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3831512
Actually, the problem is that a periodic Linux cron job cleans the /tmp directory and
the embedded Jetty places the compiled JSP classes in this directory. Deleting these
means that the compiled JSP code can no longer be run - hence no web application.
Create another directory to which Jetty can
Is there a second bunch of exceptions after that? This first set shows that the
JSPServlet failed (which we know) - this servlet invokes the compiler on the target
JSP and then executes the compiled code. If there is a second group, it usually tells
more about the underlying problem. The first g
Unfortunately, client-server mode is usually the only means of connecting to hsqldb
outside of the application (JBoss) JVM. The Database Manager utility for hsqldb
requires client-server mode as the Database Manager is an AWT/Swing-based application.
More information can be found in the document
It seems like something is wrong because at least the JBoss 3.2.3 run.sh fragment is
as:
runjar="$JBOSS_HOME/bin/run.jar"
| if [ ! -f $runjar ]; then
| die "Missing required file: $runjar"
| fi
| JBOSS_BOOT_CLASSPATH="$runjar"
|
So it is somewhat of a mystery how "Missing required
Have a look at the server.log output as it generally has more stack trace information
and if you can't determine the issue from that, post the stack trace here so people
can look at that. Otherwise it is difficult to determine the exact issue for the JSP
not compiling as there are many reasons f
Under 3.2.3, Hypersonic is not deployed by default as an MBean service. Read the
contents of hsqldb-ds.xml to understand why. Essentially, unless you want access via
TCP/IP you don't need the MBean implementation and it does have an performance impact.
So there is no MBean listing for the Hypers
Did you execute run.sh from the JBOSS_HOME/bin directory? Also make sure that
JAVA_HOME is defined to point to your Java root directory. You can do that in
JBOSS_HOME/bin/run.conf.
I have the following line in my Slackware 9.1 system:
JAVA_HOME="/usr/lib/java"
Modify for your own requirements.
Trying to call "/accountlet" will never work because there is no pattern match for it
- for security reasons, anonymous servlets are not supported: a servlet is not
accessible by its servlet name. A servlet may have zero or more url patterns
associated with it. I'm not sure whether the pattern m
When you redeploy the client classes (interfaces) in the EJB deployment get unloaded
from the JVM and then reloaded. However, the WAR is using the old reference it has,
which no longer matches the client class references as they have changed in the reload.
You could try bouncing (forcing a redep
That is an old format configuration - probably 3.0.x. Use the configuration examples
from \docs\examples\jca.
You'll want the mysql-ds.xml file and copy that into your deployment directory. It
should be modified for your database login details. It will look something like this:
|
|
|
The Value Object is immutable whereas an Data Transfer Object is not. That is the
primary difference.
The pragmatic use of an entity bean is for rapid development, particularly where the
data structure has some uncertainty. In complex systems, where no precursor exists,
you sometimes find yours
20 matches
Mail list logo
