[Design of Security on JBoss] - Re: Security EJB2 and dependencies
by anil.saldhana＠jboss.com
Adrian, regarding the pooled tests, I updated the META-INF/jboss.xml to include the PreSecurityInterceptor before the SecurityInterceptor in the container configuration. The PreSI is needed to correctly establish the security context for the container on the thread.
With this change, I do not see the errors indicating lack of properties files (users/roles.properties). But the tests now fail mainly with the following messages:
| 23:04:12,964 INFO [MainDeployer] deploy, url=file:/C:/cygwin/home/asaldhana/jboss-5.0/jboss-head/testsuite/output/lib/pooled.jar
| 23:04:13,527 INFO [EjbModule] Deploying StatelessSessionWithPooledSSL
| 23:04:14,120 INFO [EjbModule] Deploying StatelessSession
| 23:04:14,120 WARN [EjbModule] EJB Deployment has no configured security domain.
| Security will be bypassed. Please verify if this is intended. Bean=StatelessSession Deployment=vfsfile:/C:/cygwin/home/asaldhana/jboss-5.0/jboss-head/testsuite/output/lib/pooled.jar
| 23:04:14,183 INFO [ProxyFactory] Bound EJB Home 'StatelessSession' to jndi 'PooledStatelessSession'
| 23:04:14,261 INFO [STDOUT] com.sun.net.ssl.internal.ssl.SSLSessionContextImpl@9
| 21807
| 23:04:14,370 INFO [ProxyFactory] Bound EJB Home 'StatelessSessionWithPooledSSL'
| to jndi 'StatelessSessionWithPooledSSL'
|
| <== LOOK BELOW FOR THE WARN MESSAGES =>
| 23:04:16,230 WARN [BaseCertLoginModule] CallbackHandler did not provide a certificate
| 23:04:16,230 WARN [BaseCertLoginModule] Domain, KeyStore, or cert is null. Unable to validate the certificate.
| <== TILL HERE ==>
|
| 23:04:16,277 INFO [ProxyFactory] Unbind EJB Home 'StatelessSessionWithPooledSSL
| ' from jndi 'StatelessSessionWithPooledSSL'
| 23:04:16,292 INFO [ProxyFactory] Unbind EJB Home 'StatelessSession' from jndi 'PooledStatelessSession'
|
Let me take a look at what the issue with the certs packaged in the archive is.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146025#4146025
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146025
16 years, 5 months
[Design of JCA on JBoss] - Re: JBAS-4662 Implementation details.
by vickyk
Adrain , while making the changes related to JBAS-4662 in the trunk I noticed that
1) The ha behavior in the xa-datasource configuration is not working as expected .
I tested the following configuration
<xa-datasource>
|
| <jndi-name>XAOracleDS1</jndi-name>
| <reauthentication-mechanism>org.jboss.resource.adapter.jdbc.vendor.DummyReauthenticationMechanism</reauthentication-mechanism>
| <user-name>scott</user-name>
| <password>tiger</password>
| <track-connection-by-tx/>
| <isSameRM-override-value>false</isSameRM-override-value>
| <connection-property name="connectionProperties">key=Value</connection-property>
| <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
| <xa-datasource-property name="URL">jdbc:oracle:thin:@localhost:1527|jdbc:oracle:thin:@localhost:1523|jdbc:oracle:thin:@localhost:1524|jdbc:oracle:thin:@localhost:1521</xa-datasource-property>
| <url-delimiter>|</url-delimiter>
| <url-property>URL</url-property>
| <!-- xa-datasource-property name="User">scott</xa-datasource-property -->
| <!-- xa-datasource-property name="Password">tiger</xa-datasource-property -->
| <!-- xa-datasource-property name="ConnectionProperties">XATransLoose=true</xa-datasource-property -->
| <min-pool-size>1</min-pool-size>
| <max-pool-size>5</max-pool-size>
| <prefill>true</prefill>
| <!-- Uses the pingDatabase method to check a connection is still valid before handing it out from the pool -->
| <!--valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name-->
| <!-- Checks the Oracle error codes and messages for fatal errors -->
| <!-- exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name -->
| <!-- Oracles XA datasource cannot reuse a connection outside a transaction once enlisted in a global transaction and vice-versa -->
| <no-tx-separate-pools/>
| <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
| <metadata>
| <type-mapping>Oracle9i</type-mapping>
| </metadata>
|
| </xa-datasource>
And I get this exception
08:04:40,585 INFO [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=XAOracleDS1' from JNDI name 'java:XAOracleDS1'
| 08:04:48,109 WARN [JBossManagedConnectionPool] Unable to fill pool
| org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Io exception: Invalid connection string format, a valid format is: "host:port:sid" )
| at org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:452)
| at org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:405)
| at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:611)
| at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.fillToMin(InternalManagedConnectionPool.java:527)
| at org.jboss.resource.connectionmanager.PoolFiller.run(PoolFiller.java:74)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.sql.SQLException: Io exception: Invalid connection string format, a valid format is: "host:port:sid"
| at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
| at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
| at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:255)
| at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:387)
| at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:414)
| at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:165)
| at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:35)
| at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:801)
| at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:297)
| at oracle.jdbc.xa.client.OracleXADataSource.getPooledConnection(OracleXADataSource.java:456)
| at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:143)
| at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:129)
| at org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:444)
| ... 5 more
| 08:04:49,844 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=XAOracleDS1' to JNDI name 'java:XAOracleDS1'
In the above configuration the last URL is valid so it should have been considered but the deployment does not consider the chain of URL's seperated by url delimiter .
2) The similar changes in the local-tx-datasource works as expected .
I have noticed that this from the logs
2008-04-23 08:04:43,856 DEBUG [org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory] (HDScanner) inside the initSelectornull
|
which appears to be coming from
private void initSelector() throws JBossResourceException
| {
| log.debug("inside the initSelector"+urlProperty);
| if(urlProperty != null && urlProperty.length() > 0)
| {
| String urlsStr = xaProps.getProperty(urlProperty);
| if(urlsStr != null && urlsStr.trim().length() > 0 && urlDelimiter != null && urlDelimiter.trim().length() > 0)
| {
| List xaDataList = new ArrayList();
I also confirmed that the JBAS-4662 changes are not causing this issue , will have to see how the Deployment builder populate the values from the MetaData into the MBeanService through the ServiceMetaData .
Any thoughts here ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146020#4146020
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146020
16 years, 5 months
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Solution of JBREM-954 and ramifications into UnifiedInvo
by ron.sigal＠jboss.com
I'm going to regurgitate all of this just to verify that I understand the issues.
1. We don't want Remoting turning an InterruptedException into a CannotConnectException because that has a negative effect in a clustered context.
2. We don't want Remoting rethrowing an InterruptedException because that could result in the application code getting an UndeclaredThrowableException.
So, we want to wrap the InterruptedException in something, other than a CannotConnectException, that will not result in an UndeclaredThrowableException .
Is that the kernel of the matter, so far?
>From the point of Remoting, I agree that the current situation is misleading, but I'm slightly uncomfortable adding a RuntimeException to the API. UnitedInvokerProxy and UnitedInvokerHAProxy are controlled by JBoss, so we can handle any API changes, but for standalone Remoting users, we would be springing on them a stealth change in the API.
Here's an alternative proposal. Remoting could turn an InterruptedException into an InterruptedIOException, which is a subclass of IOException.
1. You could argue that it's still an API change, but MicroSocketClientInvoker.transport() already declares that it throws an IOException, so it's just adding an IOException with a different message.
2. Isn't it likely that application code, EJB or otherwise, already catches and copes with IOExceptions?
Well, I guess you could argue that an IOException would be unexpected in the case of a local EJB.
I'm torn.
WDYT?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146000#4146000
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146000
16 years, 5 months
[Design of EJB 3.0] - [EJBTHREE-1315] EJB3 Client JAR(s)
by ALRubinger
On the table: To make the EJB3 Client JAR one unit as its own assembly project, or have each module responsible for creating a *-client.jar of its own.
Regarding EJBTHREE-1315, Carlo has made the assertion:
"wolfc" wrote : We should not have a client assembly project. That's just recreating the jbossall-client problem in ejb3.
As I understand the jbossall-client issues:
* Duplicate packaging (bloat) of classes already in $JBOSS_HOME/client
* Possibility that classes in jbossall-client.jar may also exist in other JARs, leading to ClassCastException if the versions are different
I don't see the relevance of those here.
However, the Plugin project must have the client JAR declared as a dependency for it to be included in the assembly. Most of these it gets transitively via EJB3 Core, however the client JAR from EJB3 Core is not there and must be specified separately. Else:
[WARNING] The following patterns were never triggered in this artifact inclusion filter:
| o 'org.jboss.ejb3:jboss-ejb3-core:jar:client'
...which leads to http://jira.jboss.com/jira/browse/EJBTHREE-1310.
So, we've gotta explicitly define the client classifier dependencies somewhere. Best option I can see is in one new project, "client". What benefits do we reap by creating single artifacts for security-client, proxy-client, etc when they're just going to be repackaged together with the full lot anyway?
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145998#4145998
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145998
16 years, 5 months