[JBoss JIRA] Created: (JBAS-4022) EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation.
by Erica Kane (JIRA)
EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation.
--------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-4022
URL: http://jira.jboss.com/jira/browse/JBAS-4022
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.4.GA
Environment: Clustered
Reporter: Erica Kane
I created a security domain in the the JBoss server login-config.xml:
<application-policy name = "webappDomain">
<authentication>
<login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag = "required">
<module-option name = "dsJndiName">java:jdbc/web</module-option>
<module-option name = "principalsQuery">select password from Users where username=?</module-option>
<module-option name = "rolesQuery">select Role, 'Roles' from Roles where username=?</module-option>
<module-option name = "unauthenticatedIdentity">guest</module-option>
</login-module>
</authentication>
</application-policy>
In jboss-web.xml, I have
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain flushOnSessionInvalidation="true">java:/jaas/webappDomain</security-domain>
<context-root>/web</context-root>
</jboss-web>
and this works perfectly for securing web pages. However, if I put the following tag in jboss.xml:
<security-domain>java:/jaas/webappDomain</security-domain>
I find that protected EJBs default to using the "other" security domain, as shown by error messages complaining about the missing user.properties file and so on (I have left "other" on the default setting of UsersRolesLoginModule).
What DOES work is to put:
<security-domain>webappDomain</security-domain>
in jboss.xml without the java:/jaas/ prefix. However, this does not match the documentation. See
http://docs.jboss.org/jbossas/jboss4guide/r4/html/ch8.chapter.html
example 8.8. Of course there the tag is set to java:/jaas/other, which for this bug would default to "other" anyway.
I think it is terribly confusing to have jboss.xml and jboss-web.xml using different forms for the security-domain, but even if this is necessary for some reason it should be corrected in the documentation. Other people appear to have run into this as well:
http://forum.java.sun.com/thread.jspa?threadID=773530
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-3942) twiddle.sh should read run.conf - and other small ehancements
by Paul Jenner (JIRA)
twiddle.sh should read run.conf - and other small ehancements
-------------------------------------------------------------
Key: JBAS-3942
URL: http://jira.jboss.com/jira/browse/JBAS-3942
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-4.0.5.GA
Reporter: Paul Jenner
The twiddle.sh script should read environment variables from run.conf in the same way as the startup and shutdown scripts do - e.g. JAVA_HOME and JAVA.
Additionally twiddle.sh should honous the JAVA environment variable instead of overwriting it with $JAVA_HOME/bin/java or "java". This makes it consistent with startup and shutdown which do honour JAVA.
Finally the header should be changed from JBoss Shutdown script to JBoss twiddle script :-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBRULES-1432) Queries Executed while Rules are Firing Causes Exceptions
by Steve Shabino (JIRA)
Queries Executed while Rules are Firing Causes Exceptions
---------------------------------------------------------
Key: JBRULES-1432
URL: http://jira.jboss.com/jira/browse/JBRULES-1432
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 4.0.4
Environment: Sun 1.5.0_04 Windows
Reporter: Steve Shabino
We have a stateful WM into which we periodically (1) insert new facts and fire rules, and (2) execute queries. Drools fails when we allow query execution in another thread during fireAllRules().
Set-up:
- Every 10 seconds, Thread A inserts some facts and calls fireAllRules(). fireAllRules() is never called concurrently with itself.
- Thread B executes many getQueryResults() calls in series (no concurrency in query execution)
Our rule base uses shadow facts for all facts and is set up this way:
conf.setAssertBehaviour(RuleBaseConfiguration.AssertBehaviour.EQUALITY);
conf.setRemoveIdentities(true);
conf.setLogicalOverride(RuleBaseConfiguration.LogicalOverride.DISCARD);
conf.setMaintainTms(true);
conf.setShadowProxy(true);
We are making some use of insertLogical().
Expected:
- Queries are run against the last consistent truth state, even while fireAllRules() is running.
Actual Behavior:
We get this exception:
Caused by: java.lang.RuntimeException: Unable to pop
at org.drools.util.PrimitiveLongStack.pop(PrimitiveLongStack.java:63)
at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:44)
at org.drools.reteoo.ReteooWorkingMemory.getQueryResults(ReteooWorkingMemory.java:90)
This bug occurs under 4.04 and 4.1 Trunk as of 1/22.
Please let us know if we can provide additional information.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBRULES-1649) Queryresult.getFactHandles() returns bad handles
by Jaroslaw Kijanowski (JIRA)
Queryresult.getFactHandles() returns bad handles
------------------------------------------------
Key: JBRULES-1649
URL: http://jira.jboss.com/jira/browse/JBRULES-1649
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.7, 5.0.0-M1
Reporter: Jaroslaw Kijanowski
Assigned To: Mark Proctor
This is present in 4.0.7 and trunk (rev. 20565)
I have following code:
TestFact tf1 = new TestFact();
TestFact tf2 = new TestFact();
FactHandle factHandle1 = workingMemory.insert(tf1);
FactHandle factHandle2 = workingMemory.insert(tf2);
workingMemory.fireAllRules();
System.out.println("Expected:");
System.out.println(tf1);
System.out.println(factHandle1);
System.out.println(tf2);
System.out.println(factHandle2);
System.out.println("Received:");
QueryResults queryResults = workingMemory.getQueryResults("getTestFacts");
for ( Iterator it = queryResults.iterator(); it.hasNext(); ) {
QueryResult result = ( QueryResult ) it.next();
System.out.println(result.get(0 ));
System.out.println( result.getFactHandles()[0] );
}
I would expect that result.getFactHandles() returns the same handle I got when I was inserting the fact into the workingmemory
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JGRP-860) GUI to test whether cluster nodes find each other ok
by Bela Ban (JIRA)
GUI to test whether cluster nodes find each other ok
----------------------------------------------------
Key: JGRP-860
URL: https://jira.jboss.org/jira/browse/JGRP-860
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
- New DiscoveryServer (GUI) which listens on a TCP socket at a given port
- Then the nodes are started and connect to the DiscoveryServer via TCP
- Connected nodes are shown in a listbox in the DiscoveryServer's GUI
- The TCP connection between a node and the DS is the *control channel*, and is independent of JGroups (doesn't use a JGroups config)
- The control channel is used to (a) register nodes and (b) send new JGroups configurations from the DS to the nodes
- The GUI has 4 tabs: UDP, TCP dynamic (TCP:MPING config), TCP static (TCP:TCPPING) and External discovery (TCP:TCPGOSSIP).
- Each tab has configuration specific options, e.g. for UDP we have
- multicast address
- multicast port
- TTL
- checkbox: use flush or not
- checkbox: use state transfer or not
- etc etc etc
There are 2 actions buttons: "Discover" and "Save config". The latter saves the current configuration to a file (XML format). The "Discovery" button sends the current config to all nodes, via the control channel. Each node then creates a channel with the received config and connects to the cluster. The DiscoveryServer GUI (which also joins the same cluster) shows all nodes in a second listbox. When the number of nodes in the first and second listbox is the same, then this shows that the config works. In that case, the user can press "Save config" and use the generated config with all cluster nodes.
- In case UDP doesn't work or a user wants a TCP based config from the onset, the user simply clicks on the TCP tab, fills in the required information and clicks on "Discover".
- The initial config for each tab is provided by the corresponding default shipped with JGroups, e.g. UDP uses udp.xml
In a second stage, we could also not just verify that the cluster can be established, but also run some perf tests over it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (SECURITY-244) Look at SecurityConfig
by Anil Saldhana (JIRA)
Look at SecurityConfig
----------------------
Key: SECURITY-244
URL: http://jira.jboss.com/jira/browse/SECURITY-244
Project: JBoss Security and Identity Management
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Fix For: NO_VERSION
(11:25:04 AM) sguilhen: anil: ping... on SecurityConfig, there is a stack of configurations... however the popLoginConfig() seems not right to me... it always re-installs the same configuration over and over instead of installing the previous configuration... can you take a look at it later?
(11:27:22 AM) sguilhen: anil: also, as I am going to inject XMLLoginConfig directly, I need somehow to change this stack to keep the XMLLoginConfig instance instead of the object name.... so I think I need to add an extra interface here to allow the use of multiple login configurations.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-6086) the root of the problem is hibernate, resultset and
by halil agin (JIRA)
the root of the problem is hibernate, resultset
and the methods of org.jboss.resource.adapter.jdbc.WrappedResultSet class.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
the root of the problem is hibernate, resultset and=20
the root of the problem is hibernate, resultset and the methods of org.jbo=
ss.resource.adapter.jdbc.WrappedResultSet class.
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------
Key: JBAS-6086
URL: https://jira.jboss.org/jira/browse/JBAS-6086
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Hibernate service, Transaction Manager (JBossTM)
Affects Versions: JBossAS-4.2.3.GA
Environment: Linux Pardus, Turkish Locale, Java jdk 1.5
Reporter: halil agin
Assignee: Steve Ebersole
Priority: Critical
when http://localhost:8080/portal is called, the error is printed on the pa=
ge. it is below.
type Exception report
message
description The server encountered an internal error () that prevented it f=
rom fulfilling this request.
exception
javax.servlet.ServletException: org.postgresql.util.PSQLException: Bu Resul=
tSet i=C3=A7inde LISTENER10_0_ s=C3=BCtun ad=C4=B1 bulunamad=C4=B1.
=09org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java=
:278)
=09javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
=09org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte=
r.java:96)
root cause
org.postgresql.util.PSQLException: Bu ResultSet i=C3=A7inde LISTENER10_0_ s=
=C3=BCtun ad=C4=B1 bulunamad=C4=B1.
=09org.postgresql.jdbc2.AbstractJdbc2ResultSet.findColumn(AbstractJdbc2Resu=
ltSet.java:2391)
=09org.postgresql.jdbc2.AbstractJdbc2ResultSet.getString(AbstractJdbc2Resul=
tSet.java:2210)
=09org.jboss.resource.adapter.jdbc.WrappedResultSet.getString(WrappedResult=
Set.java:888)
=09org.hibernate.type.StringType.get(StringType.java:18)
=09org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163)
=09org.hibernate.type.NullableType.nullSafeGet(NullableType.java:154)
=09org.hibernate.type.AbstractType.hydrate(AbstractType.java:81)
=09org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractE=
ntityPersister.java:2096)
=09org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380)
=09org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308)
=09org.hibernate.loader.Loader.getRow(Loader.java:1206)
=09org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
=09org.hibernate.loader.Loader.doQuery(Loader.java:701)
=09org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loade=
r.java:236)
=09org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
=09org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoad=
er.java:48)
=09org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoad=
er.java:42)
=09org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEnti=
tyPersister.java:3044)
=09org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(Defa=
ultLoadEventListener.java:395)
=09org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEvent=
Listener.java:375)
=09org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventLi=
stener.java:139)
=09org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoad=
EventListener.java:195)
=09org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEvent=
Listener.java:103)
=09org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
=09org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:846)
=09org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:557)
=09org.hibernate.type.EntityType.resolve(EntityType.java:379)
=09org.hibernate.type.OneToOneType.assemble(OneToOneType.java:141)
=09org.hibernate.type.TypeFactory.assemble(TypeFactory.java:420)
=09org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96)
=09org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82)
=09org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(Defa=
ultLoadEventListener.java:553)
=09org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCach=
e(DefaultLoadEventListener.java:508)
=09org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEvent=
Listener.java:357)
=09org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventLi=
stener.java:139)
=09org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoad=
EventListener.java:195)
=09org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEvent=
Listener.java:103)
=09org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
=09org.hibernate.impl.SessionImpl.get(SessionImpl.java:815)
=09org.hibernate.impl.SessionImpl.get(SessionImpl.java:808)
=09org.jboss.portal.core.impl.model.portal.PersistentPortalObjectContainer.=
getObjectNode(PersistentPortalObjectContainer.java:296)
=09org.jboss.portal.core.impl.model.portal.PersistentPortalObjectContainer.=
getObjectNode(PersistentPortalObjectContainer.java:252)
=09org.jboss.portal.core.impl.model.portal.AbstractPortalObjectContainer.ge=
tContext(AbstractPortalObjectContainer.java:112)
=09org.jboss.portal.core.impl.model.portal.AbstractPortalObjectContainer.ge=
tContext(AbstractPortalObjectContainer.java:81)
=09org.jboss.portal.core.model.portal.DefaultPortalCommandFactory.doMapping=
(DefaultPortalCommandFactory.java:72)
=09org.jboss.portal.core.controller.Controller.handle(Controller.java:252)
=09org.jboss.portal.server.RequestControllerDispatcher.invoke(RequestContro=
llerDispatcher.java:51)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:131)
=09org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(Con=
tentTypeInterceptor.java:68)
=09org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:=
38)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.core.aspects.server.PortalContextPathInterceptor.invoke=
(PortalContextPathInterceptor.java:45)
=09org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:=
38)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInte=
rceptor.java:96)
=09org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:=
38)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserIntercep=
tor.java:193)
=09org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:=
38)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.server.aspects.server.SignOutInterceptor.invoke(SignOut=
Interceptor.java:98)
=09org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:=
38)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.core.impl.api.user.UserEventBridgeTriggerInterceptor.in=
voke(UserEventBridgeTriggerInterceptor.java:65)
=09org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:=
38)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.core.aspects.server.IdentityCacheInterceptor.invoke(Ide=
ntityCacheInterceptor.java:68)
=09org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:=
38)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$po=
rtal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInter=
ceptor.java:49)
=09org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143=
606530999904530.invokeNext(TransactionInterceptor$invoke_N51436065309999045=
30.java)
=09org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
=09org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java=
:262)
=09org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143=
606530999904530.invokeNext(TransactionInterceptor$invoke_N51436065309999045=
30.java)
=09org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(Trans=
actionInterceptor.java)
=09org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:=
38)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.server.aspects.LockInterceptor.invoke(LockInterceptor.j=
ava:139)
=09org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java=
:115)
=09org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157=
)
=09org.jboss.portal.server.servlet.PortalServlet.service(PortalServlet.java=
:252)
=09javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
=09org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte=
r.java:96)
note The full stack trace of the root cause is available in the JBossWeb/2.=
0.1.GA logs.
the root of the problem is hibernate, resultset and=20
the methods of org.jboss.resource.adapter.jdbc.WrappedResultSet class.
the class file is located in ./connector/src/main/org/jboss/resource/adapte=
r/jdbc/WrappedResultSet.java=20
under src directory.
the problem definition:
the parameter named colname Or columnName of the functions get* or update*
the member functions having below format (*:means any string) are buggy.
get*(String colName, <other params>)
get*(String columnName, <other params>)
find*(String columnName, <other params>)
update*(String colName, <other params>)
update*(String columnName, <other params>)
when above functions are called, colName or columnName parameter, which ind=
icates the column names in the result set, assigned to a string which is re=
presented as upper case. However, in the result set, the column name has a =
low case representation, therefore when the below functions called in the t=
he member functions mentioned above, the wrong colName and columnName passe=
d to resultSet functions. ThereFore, no columnname found in the resultset w=
hich is not wanted.
resultSet.get*(String colName, <other params>)
resultSet.get*(String columnName, <other params>)
resultSet.update*(String colName, <other params>)
resultSet.update*(String columnName, <other params>)
For example, the parameter of function named colName has value LISTENER10_1=
_, but in the resultSet there is a column named listener10_1_. Therefore, t=
he function in the line 254 returns null, which is the root of the problem=
.
249 public Array getArray(String colName) throws SQLException
250 {
251 checkState();
252 try
253 {
254 return resultSet.getArray(colName);
255 }
256 catch (Throwable t)
257 {
258 throw checkException(t);
259 }
260 }
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
ps://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years