Never trust roseindia. That site is terrible!
It does indeed matter whether the client is in- or outside the container. The
creation of the InitialContext for example is quite different, requires more
parameters when doing so from outside the container (things like where to find
the
sacha.labou...@jboss.com wrote : hey, it seems to work!!!
That would depend on the requirements. Maybe one or another had intended
nothing to happen ;)
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4212186#4212186
Reply to the post :
Updated URL for the JBoss Wiki entry:
http://www.jboss.org/community/docs/DOC-10783
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4212191#4212191
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4212191
It's been over a year, what do you think?
Simplest solution (and the best) is to not use that POS bridge driver. It's
rubbish.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4148608#4148608
Reply to the post :
that's one option.
Far more convenient is to just use jbossall-client.jar which contains
everything you need in one handy little (in comparison) package.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4147106#4147106
Reply to the post :
you don't call business logic from JSP. You call it from servlets and use JSP
to show the results.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4146722#4146722
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4146722
why?
It's been long replaced by other versions. At the very least get the production
release of 4.0.2, but better get either 4.0.5 or 4.2.2
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4146400#4146400
Reply to the post :
this has nothing whatsoever to do with the appserver.
Check your IDE documentation, or ask in their support forum if you don't
understand the documentation and they happen to understand you.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4146050#4146050
Reply
yup. Or any decent book, or a score of existing web based tutorials. Or the
JBoss getting started documentation.
Looks like this is just another plug for someone's website.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4146051#4146051
Reply to the post :
just use a JDBC call to the sequence to determine the next value.
How to do that is database dependent, so see the sql manual for your database
on how to call sequences.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4145687#4145687
Reply to the post :
no need to turn off UAC, as long as the user under which JBoss is run has
rw(x?) access to the directories JBoss needs (so itself, any deployroots, and
logging directories).
Same as running it under Unix really.
View the original post :
no problems with 4.0.5, 4.2.1 and 4.2.2 that I can find.
Mind I use it only for local testing and development work, not to run a site on.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4145337#4145337
Reply to the post :
Vector shouldn't be used in any code written past circa 1999 anyway, except for
code that needs to talk to legacy classes like some Swing components (and even
then, I'd sooner implement my own subclasses than use the Vector based ones).
View the original post :
JBoss messaging in JBoss 5 beta 4 is fundamentally broken due to missing
classes from the core JBoss messaging libraries (known problem, see JIRA for
JBM).
You'd need to transplant a new standalone JBM version into JBAS 5b4 and hope
for the best.
View the original post :
have you tried it?
What makes you think a lock won't propagate to the database (not saying it
won't, but I'd be surprised if it didn't)?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4144717#4144717
Reply to the post :
no need to first crosspost your question and next quote yourself if you don't
get a reply inside of 5 minutes.
That's not going to make you very popular...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4144122#4144122
Reply to the post :
next time check the dates when posting...
You're half a year late replying ;)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4143764#4143764
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4143764
the persistence context exists within the context of its entities.
Without those entities it has no real meaning.
That means those entities need to be packed with the persistence context.
You might be best off restructuring your project to have a single persistence
module containing all your
For the vast majority of people the latest production release (so at the moment
4.2.2GA) is the one to use.
Only reason to use something else would be to retain commonality in client
libraries with another server running another version, or wanting to live
dangerously and experiment with the
JBoss 4.2 doesn't support @EJB injection in servlets.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4142592#4142592
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4142592
___
the jndi name you supply is different from the one under which it is mapped,
with a NameNotBoundException as the predictable result.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4142732#4142732
Reply to the post :
The correct name is java:OracleDS.
That's why the first call gives a NameNotFoundException.
The second error indicates a failure to get a bean factory in Spring.
This is a problem with your Spring configuration or the Spring integration with
JBoss, not the JNDI lookup.
View the original post :
There is no standardised way to create and maintain datasources, that's left to
the appserver implementors.
JBoss does it through these xml configuration files, others might store the
data in an internal database accessible only through a frontend of some sort,
others again might use properties
He's not using JBoss (or is but has gotten his jndi parameters from something
completely different).
He's not using EJB3, so he's asking his question in the wrong forum.
He's hijacking a dead thread for an unrelated message.
And finally he's trying to narrow his EJB stub to the home interface
remember that jndi lookups are case sensitive. It's remote, not Remote for
example.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4142246#4142246
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4142246
You're right. That would show up later.
And of course he should change his code to use the remote interface rather than
the local one unless it's running inside the ear.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141877#4141877
Reply to the post :
the client doesn't know you want to talk to JBoss...
And it will never need to know, all it needs to know is that it has a jar file
with client libraries and some properties telling it where to get an
InitialContext.
Plug in OAS jars and properties and you're talking to Oracle, plug in BEA jars
A remote EJB client using an EJB local interface?
Might be the problem.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141714#4141714
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4141714
doesn't look like this has anything to do with JBoss.
Looks like it's either something with Hibernate, the JDBC driver, the database,
or a combination of them.
Can you use the same versions of Hibernate and your JDBC driver to talk to that
database using JPA from outside JBoss?
View the
that's why servers should always be set to use UTC internally rather than local
time.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141220#4141220
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4141220
yes, forcing a jndi lookup should work, just as it would have with the J2EE 1.4
spec.
You do of course have to supply the correct jndi names.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141216#4141216
Reply to the post :
that's a network error. Make sure the URI you refer to in your
naming.properties is correct and can be reached from your client.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141215#4141215
Reply to the post :
configure a pooled datasource and you can define how many connections the pool
can contain.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141431#4141431
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4141431
looks like a problem in either your persistence unit, your datasource, or all
those EJBs.
As it's not happening to anyone else, I think we can rule out an error in JBoss.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141475#4141475
Reply to the post :
you're probably missing the section of the ejb-jar.
Something like
| interceptors
| interceptor
| interceptor-classyour_interceptor_class_name/interceptor-class
| post-construct
| lifecycle-callback-methodmethodName/lifecycle-callback-method
| /post-construct
|
check your hosts file on the server.
It may well contain a faulty line linking localhost to your actual LAN ip
address rather than 127.0.0.1
And make sure you call the server from other systems with its real address, not
with http://localhost:8080; (you'd be astounded when you see how often
yes, check your hosts file. But that should probably not prevent you from
accessing localhost (unless of course that was mapped to something weird, like
a disconnected network card).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141043#4141043
Reply to the
ugly, a dirty hack to get around a restriction imposed by JEE for security
reasons.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4140025#4140025
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4140025
The failure of @EJB binding in JBoss 4 in servlets is documented.
JBoss 4 does not fully implement the JEE5 standard, and that's one of the
omissions.
What happens when you remove the ejb/ from the JNDI names?
Check (with that new bean not included in the application of course so it
deploys)
no, I'm saying that the way JBoss does things (i.e. disallowing you from
accessing the resources in one application in another unless they're packed
together in an ear-file) is correct.
That's the way things should be, hacking around that restriction is a bad idea.
View the original post :
you are confusing 2 use cases.
When deploying your exploded jars you're effectively deploying 2 enterprise
applications.
Those don't share resources, including persistence units.
When deploying them both packaged into a single ear file they are part of a
single enterprise application and can
there's a lot in the configuration guide about that.
Basically you have to provide a (or more if you have multiple databases)
xxx-ds.xml files in the deploy directory, and associated jar files for the
drivers in the lib directory of the server (xxx/server/default/lib and
just a question: are you trying to access localhost:8080 from the same computer
you have JBoss running?
If not it will of course never work.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4139913#4139913
Reply to the post :
those are all classpath issues. Resolve those (both linking to your own and
JBoss files and things should start to look brighter.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4139915#4139915
Reply to the post :
if I understand the rules correctly, once you put resources in an earfile
they're accessible from all components inside that earfile.
When deployed outside of the content of that earfile, those resources are no
longer so available, instead becoming local to the application that deploys
them.
treespace wrote : I bought a Ruby book and flipped through some others. One
thing struck me was the amount of time they generally spend saying how great
the language is with hardly a word on how the language is great. In fact
they appear to deliberately dodge what's good about it and fail to
check your port assignments.
Some IDEs will open ports for things like remote debuggers and autoupdate
options that can conflict with ports needed by other applications.
See if JBoss will start when Notbeans is shut down, then try to start Notbeans
with JBoss running.
View the original post :
When trying to deploy an application on JBoss 3.2.7 we get (since today, could
start the server yesterday) the following error (with the application failing
to deploy):
anonymous wrote : 15:30:45,293 ERROR [MainDeployer] Could not initialise
deployment:
Thanks for the quick reaction.
The discovery caused quite a bit of panic in our office (we're running
something like a dozen production servers and a similar number of
development/test machines on 3.2.7 still, not quite done yet converting
everything to run flawlessly under 4.x).
View the
Often the problem isn't that the user doesn't know he's posting incomplete
questions or posting them in the wrong place but that the user doesn't care.
This may be less prevalent here than in other forums (like the Sun forums for
example).
Combine that with an attitude of expecting instant
wstx.jar is missing. I found the project here: http://woodstox.codehaus.org/
Haven't tried (yet) if simply plugging it in is enough though
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4071494#4071494
Reply to the post :
Ubuntu by default doesn't like you to run servers (more specifically, open
serverports).
It's configured out of the box as a client operating system for endusers, and
many things that when endusers do them are security risks (or more often done
to them by trojans) are simply not allowed.
You
the container can take EJB3 and EJB2 at the same time, but they can NOT be part
of the same deployment archive (EJB Jar, maybe even EAR).
That's per the spec btw.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4026939#4026939
Reply to the post :
that's almost always a problem when you try to call EJBs in application servers
running a different version of the same software.
You may be able to deploy the clientside archives from JBoss 3 into your ear
file that you deploy on JBoss 4, but mind that this could lead to problems
trying to
the installer can install support for things like EJB3 so most likely contains
newer (and possibly more) jars than the zip.
You can just zip the installation directory created by the installer and have
your own zipped version.
JBoss 4.0 works very well with 1.5, in fact it requires it for some
no, at least not without some custom plumbing. The bean is removed either on a
client request or on a connection timeout.
You could code some sort of keepalive service that polls a client for a
connection regularly.
But that would require a custom client library as well which would respond to
It sounds like you're trying to either access a collection that has fetch set
to lazy, or are trying to modify a collection that's guarded by a transaction
outside the scope of that transaction.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4021592#4021592
Your JSP page is calling ANT?
Sounds like a very strange configuration you have there, and hardly surprising
it fails, especially if you didn't take care to have ANT available in the lib
directory of the web application.
View the original post :
in the lib doesn't mean anything really.
What lib for example? If that lib on the classpath for the servlet?
And even if it is, that doesn't mean the required classes are as ANT has of
dependencies of its own.
You'd best read the ANT documentation on how to integrate ANT tasks into your
just replace it with a servlet or JSP that just does a forward or redirect of
the request to the new address.
If you change the contentroot you may loose the admin and jmx consoles.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4021515#4021515
Reply to the
just replace it with a servlet or JSP that just does a forward or redirect of
the request to the new address.
If you change the contentroot you may loose the admin and jmx consoles.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4021514#4021514
Reply to the
The server itself has an embedded database, but you're not required to use it.
So just create your application without using any DataSources or other database
related resources, and Bob's your uncle.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4019882#4019882
no, it's not. A database is REQUIRED for JMS.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4020422#4020422
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4020422
___
jboss-user
And that's completely wrong, as I've seen in other default Linux installations.
Should be just (at least that line):
127.0.0.1 localhost
and make sure localhost isn't mapped to anything else (when I set up my box
sometime 2005 it inserted a line mapping localhost to my actual network
Information in general about application server architecture, or information
specific to JBoss?
If the latter, check the documentation (and/or the codebase).
If the former, a more general purpose forum would be a better place to start.
View the original post :
would have been more secure to give full access to just your account or
accountgroup, yes.
But seeing the number of machines that have only a root account which is used
for everything it's no less secure than the majority of servers out there.
View the original post :
The reason for that is simple: the object you get back is not the actual bean
but a proxy to the bean that implements the same interface.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4018454#4018454
Reply to the post :
and make sure you set $JAVA_HOME/bin at the very front of your $PATH or it
still will try to use that blasted gcj.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4018455#4018455
Reply to the post :
one more reason to NOT use scriptlets in JSPs.
All that code belongs in a servlet, NOT a JSP (in fact no Java code at all
should be in JSPs).
What you're trying to do is extremely illegal. It will never work. The
outputstream is after all private to the JSP and created implicitly when it's
P.S. this has nothing to do with JBoss, it's servlet/JSP basics.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4018457#4018457
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4018457
You would certainly have to rewrite the whole thing (or at least greatly modify
it) if you want to do something like that.
Load balancing and clustering is done on a request/response basis, with the
cluster admin server determining which member of the cluster gets to handle a
request.
If I
Seems you're trying to debug the servlet by running it as an application.
That's not the way to do it.
You need to connect to the web application (the servlet module) running inside
JBoss and set some breakpoints.
Then do an HTTP request to the servlet (using a web browser usually) and see
the
Don't put that there. An array isn't a valid serializable object (and putting
fields in an interface is an established Bad Thing (tm) according to Josh
Bloch, though sometimes handy for cases like this).
Best change that array to 2 separate String fields (I assume they're allowed
values for
You'll have to get it running on a machine that can be seen outside your own
network, that's all there is to it.
Of course the devil is in the details, like security, probably getting a DNS
name for it, where to host the server, etc. etc. etc.
View the original post :
That's a function of the firewall. It probably forwards requests to DNS entries
to the proper machine, but if you give the IP address of the firewall itself it
will try to resolve them to itself.
foo in your case will be a URL that maps to the machine your appserver is
running on in the DNS
There doesn't have to be a problem, yet I do in my own experience notice that
those OS tools that have (large) corporations behind them are generally far
superior to those that don't.
Not just stability (will it be actively maintained in a few months and will
there be support when and if I need
76 matches
Mail list logo
