JBoss and SSL
by Cristian
Hi everybody,
I have an issue setting JBoss according to this page:
http://www.jboss.org/wiki/Wiki.jsp?page=SSLSetup, authentication
scenario no. 3.
I'm using jboss 4.2.2.GA and JDK 1.5.0 update13.
Everything at step 3 went according to the description there: ant
builds, certs import into the browser, jboss settings.
The connector part in server.xml is as follows:
<Connector
port="8443" address="0.0.0.0"
maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
scheme="https" secure="true" clientAuth="true"
keystoreFile="/opt/jboss/server/default/conf/server.keystore"
keystorePass="servercert"
truststoreFile="/opt/jboss/server/default/conf/server.truststore"
truststorePass="servercert"
sslProtocol = "TLS" />
The server.keystore and server.truststore are in place as well as
everything else. JBoss does not have APR enabled.
The problem is that if I'm trying https://host:8443/ it just connects to
8443 (I can see it with netstats) and that's all.
The browser used was Mozilla Firefox.
I'm not warned/prompted for anything and after a while the connection
dies, of course.
I'm completely unaware about all the mechanisms that make JBoss work.
I'm trying though.
Can you give me a hint about what's to be done in order to make it work
with this auth scenario?
Thanks,
Cristian
18 years, 6 months
[JBoss Seam] - Re: Problems using Authenticator.authenticate()
by appendix
Hi!
I was giving this whole authentication and undetermined number of calls to authenticator.authenticate() some thoughts and my workaround is that I'm using my own LoginHandler.
This one is called from the LoginPage and acts as a regular JSF Bean, hence can determine the next rendered page by returning given outcomes. It uses the Identity component, so the rest of the nice features (like using identity.loggedIn,...) can still be used.
Also here the authentication is performed only once, because the method is called only once per request.
The actual authenticator.authenticate method just uses the results from the LoginHandler to return true or false.
With this, the database is able count the actual login attempts and the authenticator.authenticate method can be called as often as it might get ...
I'm still unclear, why and in which circumstances the authenticator.authenticate() method is called from Seam, but I guess it's a useable workaround for me.
For example, the authenticator.authenticate() method is called even if the login page is calling some other method than identity.login - haven't had time to dig into this ...
Best regards, Kurt
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102170#4102170
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102170
18 years, 6 months
[JBossWS] - Re: JBoss Transaction Integration Status
by adinn
Hi Ted,
Before answering your question I'll just note that the current XTS package in JBossTS already allows JaxWS clients and servers to participate in transactions using the 1.0 WSCOOR protocols. All that is need is to configure the client and server with the SOAP handlers supplied in the package. However, this WSCOOR implementation is based on a 'home-grown' soap stack embedded in the XTS implementation.
I am currently extending XTS to provide a wscoor 1.1 conformant implementation of web service transactions based on JaxWS. The WSCOOR, WSAT and WSBA 1.1 services are exposed as JaxWS endpoints. Client code will normally only access these services via a suitably configured UserTransaction or TransactionManager class but it should be possible to go 'under the hood' to configure the JaxWS layer e.g. with logging interceptors, etc.
This new XTS will rely upon on the JaxWS implementation provided by JBossWS. in App Server 5.0. However, it is not tied to the JBoss implementation, for two reasons. In AS 5.0 JBossWS is being split into a generic API layer and an implementation layer (called JBossWS-Native). This will allow alternative WS implementaions to be dropped into the AS in place of JBossWS-Native. Furthermore, the XTS implementation only relies on generic JaxWS features so it should be able to run directly over any fully compliant JaxWS 2.1 implementation, e.g. by dropping the TS and XTS implementation into a different app server.
WSCOOR 1.0 support should still be available alongside this new implementation by retaining the 'home-grown' soap stack currently embedded in the XTS package.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102168#4102168
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102168
18 years, 6 months
[EJB 3.0] - EJB3.0 Vs Normal RMI
by lovelyliatroim
Hi Guys,
I just started doing some simple tests between EJB3.0 and standalone RMI.
Im using the JRMP in both cases(well it think so, i read that jboss uses JRMP protocol out of the box for ejb3.0, and i havent changed anything).
Its just a simple test that i have, look up remote object and i call it 1,000 times for both cases. I just keep track of the time it takes and thats it.
I would have thought since both are using the same protocol that the difference wouldnt be much but there is a big difference.
Normal RMI way takes around 1-2 secs on average, ejb3(stateless bean) way takes from 7-10 seconds.
Anyone shed some light on why the big difference or is this a fair way for comparison??
Using jdk1.5_11 on xp with app server 4.2.2GA.
Cheers,
LL
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102166#4102166
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102166
18 years, 6 months