[JBoss JIRA] Created: (SECURITY-590) RequestAttributeFactory.createTimeAttributeType(attName, issuer) API call causes a parsing exception
by Asankha Perera (JIRA)
RequestAttributeFactory.createTimeAttributeType(attName, issuer) API call causes a parsing exception
----------------------------------------------------------------------------------------------------
Key: SECURITY-590
URL: https://issues.jboss.org/browse/SECURITY-590
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossXACML
Environment: Version was 2.0.6.Final
Reporter: Asankha Perera
Assignee: Anil Saldhana
Priority: Minor
Using the API call RequestAttributeFactory.createTimeAttributeType(attName, issuer) causes a "ParsingException: couldn't create http://www.w3.org/2001/XMLSchema#time attribute based on DOM node"
Note that with the above API call, we do not supply any time string, but assume that the current time is used. As a comparison the similar API call RequestAttributeFactory.createDateTimeAttributeType(attName, issuer) works without any issues - hence it seems logical that the createTimeAttributeType() contains a possible bug
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (JBAS-9424) MDB's are started *BEFORE* EJB's are jndi-bound
by Bernard Ligny (JIRA)
MDB's are started *BEFORE* EJB's are jndi-bound
-----------------------------------------------
Key: JBAS-9424
URL: https://issues.jboss.org/browse/JBAS-9424
Project: Legacy JBoss Application Server 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB, Weld/CDI
Affects Versions: 6.0.0.Final
Environment: All (*NIX, Mac-Os-X and Win)
Reporter: Bernard Ligny
Assignee: Carlo de Wolf
Priority: Critical
I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.
If the JMS queue is empty when the jboss server is started, then everything work's fine.
If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
and the @Inject failed:
=> "Failure WELD-000079 Could not find the EJB in JNDI: class xxx"
I further investigated the problem:
I replaced the @Inject annotation, with a "manual" lookup of my ejb
using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB),
The trick consisted in trying the lookup n times with a delay of x sec between each attempt.
Here are the results (excerpt from server.log):
2011-07-28 12:05:06,180 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
2011-07-28 12:05:06,190 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI: class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:11,191 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
2011-07-28 12:05:11,192 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI: class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:16,193 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
2011-07-28 12:05:16,193 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI: class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:21,194 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
2011-07-28 12:05:21,194 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI: class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:26,195 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
2011-07-28 12:05:26,195 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI: class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:26,215 INFO [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
=> finally the EJB is bound !
2011-07-28 12:05:31,196 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
2011-07-28 12:05:31,197 INFO [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
=> the 6th attempt now works :-)
Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
The app server should wait for all EJB's to be bound before activating the MDB.
MDB are activated too early (especially when jms queue is not empty at starttime)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (EJBTHREE-1343) Remove the cyclical dependency from ejb3/core to org.jboss.jbossas-jboss-as-server
by Dimitris Andreadis (JIRA)
Remove the cyclical dependency from ejb3/core to org.jboss.jbossas-jboss-as-server
----------------------------------------------------------------------------------
Key: EJBTHREE-1343
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1343
Project: EJB 3.0
Issue Type: Task
Components: core
Reporter: Dimitris Andreadis
Assigned To: Carlo de Wolf
Priority: Critical
Fix For: AS 5.0.0.CR1
ejb3/core -> jboss-as-server dependencies
------------------------------------------------------------
ejb3/core
./org/jboss/ejb3/naming/client/java/javaURLContextFactory.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.corba.ORBFactory
------------------------------------------------------------
ejb3/core
./org/jboss/ejb3/naming/client/java/javaURLContextFactory.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.naming.client.java.HandleDelegateFactory;
------------------------------------------------------------
ejb3/core
./org/jboss/ejb3/AllowedOperationsInterceptor.java
./org/jboss/ejb3/service/ServiceContainer.java
./org/jboss/ejb3/stateless/StatelessContainer.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.ejb.AllowedOperationsAssociation
ejb3/core
./org/jboss/ejb3/mdb/MessagingContainer.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.jms.jndi.JMSProviderAdapter;
org.jboss.jbossas:jboss-as-server
-----------------------------------------
ejb3/core
./org/jboss/ejb3/timerservice/jboss/JBossTimerServiceFactory.java
./org/jboss/ejb3/timerservice/TimedObjectInvoker.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.ejb.txtimer.EJBTimerService;
org.jboss.ejb.txtimer.TimedObjectInvoker
-----------------------------------------
ejb3/core
./org/jboss/ejb3/stateful/StatefulLocalProxyFactory.java
./org/jboss/ejb3/stateless/StatelessContainer.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.proxy.ejb.handle.StatefulHandleImpl;
org.jboss.proxy.ejb.handle.HomeHandleImpl;
------------------------------------------
ejb3/core
./org/jboss/ejb3/AllowedOperationsInterceptor.java
./org/jboss/ejb3/ContainerPlugin.java
./org/jboss/ejb3/service/ServiceContainer.java
./org/jboss/ejb3/stateless/StatelessContainer.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.ejb.AllowedOperationsFlags
-------------------------------------------
ejb3/core
./org/jboss/ejb3/EJBProxyFactory.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.invocation.Invocation
--------------------------------------------
ejb3/core
./org/jboss/ejb3/EJBProxyFactory.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.ejb.GenericEntityObjectFactory
--
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
14 years, 7 months
[JBoss JIRA] Created: (AS7-775) Specify default values for the urn:jboss:domain:transaction object-store
by Scott Stark (JIRA)
Specify default values for the urn:jboss:domain:transaction object-store
------------------------------------------------------------------------
Key: AS7-775
URL: https://issues.jboss.org/browse/AS7-775
Project: Application Server 7
Issue Type: Feature Request
Components: Transactions
Affects Versions: 7.0.0.Beta3
Reporter: Scott Stark
Assignee: Jason Greene
I see the tm file stores being created in whatever the working directory of the server happens to be rather than under the jboss.server.data.dir. It appears that in the absence of a configuration like the following:
<subsystem xmlns="urn:jboss:domain:transactions:1.0">
...
<object-store relative-to="jboss.server.data.dir" path="."/>
</subsystem>
that the TransactionSubsystemAdd should be defaulting to a location under the jboss.server.data.dir, but that does not appear to be working. Either the default needs to be added to the configurations, or corrected in the TransactionSubsystemAdd code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (JGRP-1330) Dispatcher: incorrect RspFilter impl should not prevent termination of call
by Bela Ban (JIRA)
Dispatcher: incorrect RspFilter impl should not prevent termination of call
---------------------------------------------------------------------------
Key: JGRP-1330
URL: https://issues.jboss.org/browse/JGRP-1330
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.1
When a RspFilter returns false for isAcceptable() for all responses and needMoreResponses() returns true all the time, then a call would block forever (if timeout=0), or until the timeout kicks in.
This should be prevented; the new behavior would be:
GET_ALL:
- Terminate when the filter indicates it has sufficient responses (needMoreResponses() == false) OR when responses from all members have been received.
- The current behavior requires the RspFilter to keep track of responses and terminate when no suitable responses have been received from all members
GET_FIRST:
- Terminate the call when 1 suitable response has been received, or when uisuitable responses from all members have been received
Of course, both GET_FIRST and GET_ALL are also bounded by the timeout, as it currently the case.
Similar behavior would exist for GET_MAJORITY
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (JGRP-1323) MERGE2 not getting all the coordinators from PING
by vivek v (JIRA)
MERGE2 not getting all the coordinators from PING
-------------------------------------------------
Key: JGRP-1323
URL: https://issues.jboss.org/browse/JGRP-1323
Project: JGroups
Issue Type: Bug
Affects Versions: 2.10
Environment: Windows, Linux
Reporter: vivek v
Assignee: Bela Ban
We got 17 nodes in our group. Due to some node up/down the group got divided into two partitions. One partition had only 2 nodes in it and the other had 16. Even after all the nodes were up we never got the merge between the two partitions. Here is what I see from the logs,
1) On Partition 1 (coordinator: manager_192.168.50.22)
{noformat}
2011-05-11 01:18:48,980 TRACE [Timer-1,192.168.50.22_group,manager_192.168.50.22:4576] PING - discovery took 5002 ms: responses: 7 total (7 servers (1 coord), 0 clients)
2011-05-11 01:18:48,980 TRACE [Timer-1,192.168.50.22_group,manager_192.168.50.22:4576] MERGE2 - Discovery results:
[manager_192.168.50.22:4576]: [manager_192.168.50.22:4576|19] [manager_192.168.50.22:4576, probe_192.168.50.80:4576]
[probe_192.168.50.65:4576]: MergeView::[probe_192.168.50.66:4576|30] [probe_192.168.50.66:4576, probe_192.168.50.64:4576, probe_192.168.50.59:4576, probe_192.168.50.58:4576, probe_192.168.50.81:4576, probe_192.168.50.63:4576, probe_192.168.50.80:4576, collector_192.168.50.23:4576, probe_192.168.50.65:4576, probe_192.168.50.62:4576, probe_192.168.50.60:4576, probe_192.168.50.69:4576, probe_192.168.50.68:4576, probe_192.168.50.83:4576, probe_192.168.50.82:4576, probe_192.168.50.61:4576, probe_192.168.50.67:4576], subgroups=[..
..
011-05-11 01:18:49,034 DEBUG [ViewHandler,192.168.50.22_group,manager_192.168.50.22:4576] GMS - determining merge leader from [probe_192.168.50.68:4576, probe_192.168.50.66:4576, probe_192.168.50.61:4576, manager_192.168.50.22:4576, probe_192.168.50.69:4576, probe_192.168.50.58:4576, probe_192.168.50.65:4576, probe_192.168.50.60:4576, probe_192.168.50.64:4576, probe_192.168.50.81:4576, probe_192.168.50.67:4576, collector_192.168.50.23:4576, probe_192.168.50.63:4576, probe_192.168.50.82:4576, probe_192.168.50.83:4576, probe_192.168.50.62:4576, probe_192.168.50.59:4576]
2011-05-11 01:18:49,036 DEBUG [ViewHandler,192.168.50.22_group,manager_192.168.50.22:4576] GMS - I (manager_192.168.50.22:4576) am not the merge leader, waiting for merge leader (probe_192.168.50.66:4576) to initiate merge
{noformat}
2) On Partition 2 (probe_192.168.50.66)
{noformat}
2011-05-10 21:03:07,334 TRACE [Timer-1,192.168.50.22_group,probe_192.168.50.66:4576] PING - discovery took 47 ms: responses: 17 total (17 servers (1 coord), 0 clients)
2011-05-10 21:03:07,335 TRACE [Timer-1,192.168.50.22_group,probe_192.168.50.66:4576] MERGE2 - Discovery results:
[probe_192.168.50.66:4576]: MergeView::[probe_192.168.50.66:4576|30] [probe_192.168.50.66:4576, probe_192.168.50.64:4576, probe_192.168.50.59:4576, probe_192.168.50.58:4576, probe_192.168.50.81:4576, probe_192.168.50.63:4576, probe_192.168.50.80:4576, collector_192.168.50.23:4576, probe_192.168.50.65:4576, probe_192.168.50.62:4576, probe_192.168.50.60:4576, probe_192.168.50.69:4576, probe_192.168.50.68:4576, probe_192.168.50.83:4576, probe_192.168.50.82:4576, probe_192.168.50.61:4576, probe_192.168.50.67:4576], subgroups=[[..
{noformat}
The FIND_INITIAL_MBRS by second coordinator (probe_192.168.50.66) never get the manager in it's list. We are using Tunnel protocol stack with two Gossip Router. Both the coordinators are talking to the same GR. Here is our PING and MERGE configuration,
{code:xml}
<PING timeout="5000"
num_initial_members="3"/>
<MERGE2 max_interval="30000" min_interval="10000"/>
{code}
On coordinator 2 I also see,
{noformat}
2011-05-10 21:05:30,959 WARN [OOB-2330,192.168.50.22_group,probe_192.168.50.66:4576] NAKACK - probe_192.168.50.66:4576: dropped message from manager_192.168.50.22:4576 (not in xmit_table), keys are [probe_192.168.50.60:4576, probe_192.168.50.63:4576, ...
...
{noformat}
MERGE2 seems to rely on DISCOVERY to get initial members, but for some reason the two partitions are getting different results. Could it be because the Partition 1 got only two members in it so it wait for the other members to give its view as well, but Partition 2 has a long list of members so it gets the view from them and doesn't wait for the Partition 1 list.
Partition 1 also seem to wait for the merge leader - do we need to do that? In this case the merge leader never comes by and thus, the merge between two subgroup never happen.
I'm not sure where the exact problem is, but I'm opening this as bug as we've seen disjoint groups never merging on quite a few occasions.
Attached are detailed logs from the two coordinators.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (JGRP-726) GossipRouter: support GET and REGISTER via UDP datagram packets
by Bela Ban (JIRA)
GossipRouter: support GET and REGISTER via UDP datagram packets
---------------------------------------------------------------
Key: JGRP-726
URL: http://jira.jboss.com/jira/browse/JGRP-726
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.8
Currently, GossipRouter supports only TCP. If a GossipClient calls register() or getMembers(), then a TCP connection is established and torn down after the request. This is inefficient and leads to many sockets in TIME_WAIT states (which are cleaned up after 2 * MSL seconds).
If we (in GossipRouter) add an additional listener, which listens on a UDP port, and provide the same for GossipClient, we would not use precious TCP sockets.
Think about: we should separate the transport in GR from the processing logic, so we could support TCP, UDP, HTTP etc. Should we use JGroups (in unicast mode) for this ?
--
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
14 years, 7 months