Oops! It looks like I made a mistake. In the above document, I should have
said that the stuff goes in the "jboss-app.xml" file in the
META-INF folder and not in the jboss.xml file.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3908711#3908711
Reply to
Nice work, Vishal. I will give that a try. Just like everything else in J2EE,
there's probably some downside to going this route. I'll check out the doc but
do you know of anything 'bad' about using this technique?
Spoon
View the original post :
http://www.jboss.org/index.html?module=bb&op=
In the jboss.xml file there is a "loader-repository" element designed to permit
two EARs with similar contents to be deployed without interference.
The modules inside an application often contain compiled Java classes.
EJB-JARs always have classes in them. Maintaining uniqueness among class na
... in your ejb-jar.xml? With some more information I can tell what's wrong.
You will also find that every app server vendor adds their own features to
EJB-QL so some fancy things that work on one server might not work on another.
It doesn't look like you are doing anything too fancy, but I'd
Like a code example of the code that is causing this error? Maybe it's the
argument you are passing to the finder method?
Spoon
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3873157#3873157
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=p
I find that whenever I redeploy an EJB-JAR, any web apps that had already been
using those EJBs also need to be redeployed. I don't know the true technical
reasons for it but it seems pretty consistent to me.
If it's true, the reason why it all seems to work after restarting the JBoss
server i
Did you write code for this query? It's my understanding that you never have
to write any SQL or EJB-QL for either findAll() or findByPrimaryKey() If you
have written some SQL or EJB-QL, maybe you are making problems for yourself.
public ComponentIntf findByPrimaryKey(primaryKeyDataType pk) t
when accessing EJBs remotely from a separate JVM. I don't really know for
sure but I've always worked from the assumption that one server's JNDI
directory only listed things from the same JVM, but I don't really know a lot
about JNDI.
Every time I've had the client and the EJB server runni
I realize that I'm not giving enough information right now for you to actually
DO what I suggest, but I might be able to help with some details if you are
interested in this approach.
In JBoss, you can use XML files in the \deploy directory to declare
datasources, for example, a file called mys
are you using a real hostname in your jndi.properties file or does your
actual file look exactly as you posted it?
If so, take a look at this line:
java.naming.provider.url=jnp://:1099
You really need a hostname and cannot leave it as
Let me know because I have lots of experience getting
It appears difficult to find a conceptual explanation of when the reentrant
node in an entity bean should be set to true. I realize that deep under the
covers it has to do with concurrency and allowing multiple threads to access
the same instance of an entity bean, blah, blah, blah, but I am a
Have a look at the topic I posted late last night. It explains my problem and
may shed some light on yours as it encompasses the majority of what I have
learned while experimenting.
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=62187
View the original post :
http://www.jboss.org/in
You did manage to make it work but that's not really the way you want to do it.
You need something more dynamic in your JSP than a hard-coded context root.
If, for example, you change the context root, you will have to change the
hardcoded path in every img tag. Yuck!
Instead, you should com
I'm using JBoss/Tomcat bundle JBoss version 3.2.7 running on XP SP2
I've been studying and experimenting all day with the various ways of
implementing JSP error pages. It appears that there are 2 ways:
1) map HTTP error codes or Java Exception classes to error pages via web.xml
deployment desc
If anyone is still interested, I believe I can help. I've been working on
these puzzles for about 14 hours now and have many correct answers.
Spoon
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872466#3872466
Reply to the post :
http://www.jboss.org/index
I find some trouble when using BOTH the 500 error thing AND an exception class
thing in the DDs at the same time. If I only do one or the other, I get better
results.
Overall, I am having lots of trouble getting the stuff to work as
advertised. Between using some stuff and some JSP page
di
Complete Success!
I have gotten BOTH the JNDI login and the LoginContext way working.
Does anyone know of a way to Logout when using the JNDI way? Since the
LoginContext is abstracted when going this route, I don't see a way to execute
a logout() method.
Any ideas?
Spoon
View the origin
as I finally got it all working. Thanks so much for your continued interest in
this problem.
One problem was the JVM version that Notes uses: 1.3.1 By installing the
1.3.1 J2SEEJDK thing, I had the right version of j2ee.jar. Then I had to add a
JavaUserClasses entry in the notes.ini file (t
Throughout all of this research and discussion, I have decided to try to create
another control in this experiment. I have been running a web app and an
ejb-jar both on the same JBoss server thus all of the contact between the web
app as the client and the ejb container was within the same JVM.
Being the novice Java guy I am, I've never really been able to make much out of
a stack trace but here you go. It's all of the System.out stuff including my
silly little messages so that I know which line of code explodes.
I tried putting a JAR file containing the javax.xml.parsers classes in
I've become a little bit suspect of something in my java.security file:
| #
| # Class to instantiate as the javax.security.auth.login.Configuration
| # provider.
| #
| login.configuration.provider=com.sun.security.auth.login.ConfigFile
|
So it makes me wonder. Am I using the correct
To try to divide and conquer this problem some more, I've decided to attack the
java.security and java.policy files in the jvm\lib\security directory of the
Lotus Notes JVM. These files and their behaviors ought to be fairly normal for
a JVM regardless of whether its running inside Notes or not
Thanks so much for posting those URLs but there was almost nothing about the
java.security.auth.login.config (i.e. mentioned only once)
and nothing at all about how to include a auth.conf file in any way other than
using the -Djava approach.
Now, I realize that I'm maybe using a JVM that somehow
Mine is still not. Like every other Java/J2EE puzzle, you just have to keep
slugging it out until you get it. There's just no other way...
I'm increasingly more convinced that my problem is related to not having a way
to tell my JVM where the auth.conf file is. Every reference I can find says
It looks like several of us are all working on the same problem and having the
same difficulties. I have seen many partial answers and many partial code
examples and I have read just about everything there is on this topic yet I
cannot get it to work either.
As I understand that there are 2 wa
It turns out that the client application is forced to use a 1.3.x JVM for some
architectural reasons that I can't change. So, we'll stick with JBoss 3.2.x
until we grow out of our old JVM.
Thanks, Scott.
Spoon
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&
I have a stand-alone Java client that needs to be able to get an initial JNDI
context. It worked fine in JBoss 3.2.x but no longer works when I run it
against a JBoss 4.0.x server. The trouble is that at runtime, my client cannot
get an initial context because of the NoClassDefNotFoundError wh
27 matches
Mail list logo
