[JBoss JIRA] Created: (JBRULES-2743) GWT exception handler: any exception thrown on the client (or server) must result in a dialog for the user. Depending on the exception class the message and blame (user vs programmer) differs
by Geoffrey De Smet (JIRA)
GWT exception handler: any exception thrown on the client (or server) must result in a dialog for the user. Depending on the exception class the message and blame (user vs programmer) differs
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2743
URL: https://jira.jboss.org/browse/JBRULES-2743
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-guvnor
Affects Versions: 5.1.1.FINAL
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Priority: Critical
Fix For: 5.2.0.M1
<Rikkola> you can use ErrorPopup for them
<ge0ffrey> in spring-rcp I wrote a whole exception handling system
<ge0ffrey> basically you can configure it to handle exceptions differently than other exceptions
<ge0ffrey> NPE, IllegalArgument, ... => Programmers fault, big red error button with a "report error" button
<ge0ffrey> AuthorizationException,AuthenticationException, hibernate-validator InvalidStateException => users fault, yellow triangle
<ge0ffrey> and the ability to provide exception type specific messages
<Rikkola> sounds good
<ge0ffrey> NotUniqueException => dear user, you're record is not unique, please pick another value
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBVFS-167) Allow the temp directory to be set on the TempFileProvider
by Thomas Diesler (JIRA)
Allow the temp directory to be set on the TempFileProvider
----------------------------------------------------------
Key: JBVFS-167
URL: https://jira.jboss.org/browse/JBVFS-167
Project: JBoss VFS
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 3.0.0.CR5
Reporter: Thomas Diesler
Assignee: John Bailey
In OSGi we would like to store the VFS temp files that relate to bundle deployments in the persistent bundle storage area which is maintained by the Framework across Framework instances.
Currently this can only be configured via system props
static {
String configTmpDir = System.getProperty(JBOSS_TMP_DIR_PROPERTY);
if (configTmpDir == null)
configTmpDir = System.getProperty(JVM_TMP_DIR_PROPERTY);
try {
TMP_ROOT = new File(configTmpDir, "vfs");
TMP_ROOT.mkdirs();
}
catch (Exception e) {
throw new RuntimeException("Can't set up temp file provider", e);
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (EJBTHREE-2183) @AccessTimeout with values 0 or -1 should be treated differently than positive values
by jaikiran pai (JIRA)
@AccessTimeout with values 0 or -1 should be treated differently than positive values
-------------------------------------------------------------------------------------
Key: EJBTHREE-2183
URL: https://jira.jboss.org/browse/EJBTHREE-2183
Project: EJB 3.0
Issue Type: Bug
Components: concurrency
Affects Versions: depchain-1.0.0-alpha-4
Reporter: jaikiran pai
Assignee: jaikiran pai
The EJB3.1 spec, section Section 4.8.5.5.1 says:
"An @AccessTimeout value of -1 indicates that the client request will block indefinitely until forward progress can be made.
An @AccessTimeout value of 0 indicates that concurrent access is not allowed. Access attempts on methods with a timeout value of 0 result in a javax.ejb.ConcurrentAccessException."
We currently don't handle these values and just pass them to Lock.tryLock(), which as per its javadoc says:
"If the time is less than or equal to zero, the method will not wait at all. "
This breaks the EJB3.1 spec expectation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBREM-1255) Classname redundancy in Remoting.addServices()
by Ron Sigal (JIRA)
Classname redundancy in Remoting.addServices()
----------------------------------------------
Key: JBREM-1255
URL: https://jira.jboss.org/browse/JBREM-1255
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Priority: Minor
Fix For: 3.1.0.Beta3
In org.jboss.remoting3.Remoting.addServices()
private static <T> void addServices(final Endpoint endpoint, final ProtocolServiceType<T> serviceType, final Properties props) {
final String basePropName = serviceType.getName().toLowerCase();
final String instances = props.getProperty(endpoint.getName() + "." + basePropName + "_list");
final Class<T> valueClass = serviceType.getValueClass();
if (instances != null) {
for (String name : instances.split(",")) {
final String trimmed = name.trim();
final String className = props.getProperty(name + "." + basePropName + "." + trimmed + ".class"); // <<<=====
if (className != null) {
try {
final Class<? extends T> instanceType = Class.forName(className).asSubclass(valueClass);
final T instance = instanceType.getConstructor().newInstance();
log.trace("Adding protocol service '%s' of type '%s'", name, serviceType);
endpoint.addProtocolService(serviceType, name, instance);
} catch (InvocationTargetException e) {
log.warn(e.getCause(), "Unable to create %s instance '%s'", serviceType, name);
} catch (Exception e) {
log.warn("Unable to register %s '%s': %s", serviceType, name, e);
}
}
}
}
}
the line labelled <<<==== has what seems to be the redundant use of name and trimmed. As a result, the property it's looking for ends up looking like, for example, "mockClassResolver.class_resolver.mockClassResolver.class". I suspect it should be "class_resolver.mockClassResolver.class".
Note that the property file jboss-remoting/src/test/resources/protocols.test.remoting.properties, used by org.jboss.remoting3.test.EndpointConfigurationTestCase, is written to work with this redundancy. It should be changed if the code is changed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBREM-1250) Buffer size mismatch between RemoteConnectionHandler and FramingChannelListener
by Ron Sigal (JIRA)
Buffer size mismatch between RemoteConnectionHandler and FramingChannelListener
-------------------------------------------------------------------------------
Key: JBREM-1250
URL: https://jira.jboss.org/browse/JBREM-1250
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Fix For: 3.1.0.Beta3
Currently,
client.invoke(new byte[1024 * 8 - 6]);
works, but
client.invoke(new byte[1024 * 8 - 5]);
hangs.
The problem is that on the sending side,org.jboss.remoting3.remote.RemoteConnectionHandler hard codes a buffer size of 65536:
private final Pool<ByteBuffer> bufferPool = Buffers.createHeapByteBufferAllocator(65536);
so the sender can transmit up to 65535 bytes at a time. But on the receiving side, FramingChannelListener defaults to a buffer size of 4 * 2048:
FramingChannelListener(final OptionMap optionMap, final AbstractMessageHandler messageHandler) {
this.messageHandler = messageHandler;
maxSize = optionMap.get(Options.MAX_INBOUND_MESSAGE_SIZE, 2048);
receiveBuffer = ByteBuffer.allocate(Math.min(optionMap.get(RemotingOptions.BUFFER_SIZE, maxSize * 4), 4096));
}
Sending new byte[1024 * 8 - 5] results in a message with a 2 byte length field followed by 6 header bytes plus 8187 content bytes, where the length field holds 8193. On the receiver side,org.jboss.remoting3.remote.FramingChannelListener has a buffer of default size 8192. FramingChannelListener.handleEvent() wants to get 8193 bytes and it sits in a loop calling handleBufferedData(), which keeps returning because the 8192 byte buffer never holds 8193 bytes:
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123].handleEvent(): receiveBuffer.remaining(): 0
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123].handleBufferedData()
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] state: BODY
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] initial == BODY, size == 8193, remaining == 8192
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] returning because remaining < size
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123].handleEvent(): receiveBuffer.remaining(): 0
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123].handleBufferedData()
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] state: BODY
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] initial == BODY, size == 8193, remaining == 8192
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] returning because remaining < size
.
.
.
When the buffer size is changed to 4 * 16384
maxSize = optionMap.get(Options.MAX_INBOUND_MESSAGE_SIZE, 16384);
the problem goes away.
There should be two changes:
1. The default buffer sizes should be compatible.
2. The buffer size in RemoteConnectionHandler should be configurable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBREM-1249) RequestContextImpl is unable to send an exception thrown while sending a reply
by Ron Sigal (JIRA)
RequestContextImpl is unable to send an exception thrown while sending a reply
------------------------------------------------------------------------------
Key: JBREM-1249
URL: https://jira.jboss.org/browse/JBREM-1249
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Fix For: 3.1.0.Beta3
In org.jboss.remoting3.test.remote.RemoteMessageHandlerTestCase, test method testReplyExceptionAbort() (currently commented) sends an exception over the wire, and the request listener sends it back. But on the return trip, the exception's writeObject() method throws an exception. So
1. RequestContextImpl.sendReply() calls OutboundReplyHandler.sendReply() to write the exception for its return trip
2. OutboundReplyHandler.sendReply() tries to write the exception
2. the exception's writeObject() throws an exception
3. RequestContextImpl.sendReply() catches the exception and calls
SpiUtils.safeHandleException(replyHandler, new RemoteReplyException("Remote reply failed", e));
4. SpiUtils.safeHandleException() calls OutboundReplyHandler.handleException().
The problem is that the call to OutboundReplyHandler.sendReply() sets OutboundReplyHandler.done to true, and the call to OutboundReplyHandler.handleException() turns into a no-op.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBAS-8352) Stacked login with subclassed Principal does not work.
by Craig Horrell (JIRA)
Stacked login with subclassed Principal does not work.
------------------------------------------------------
Key: JBAS-8352
URL: https://jira.jboss.org/browse/JBAS-8352
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.1.0.GA
Environment: Windows XP; Jboss 5.1.0.GA;
Reporter: Craig Horrell
Assignee: Anil Saldhana
The Principal is not propagated from login module to login module when using stacked logins. Instead, a new Principal is created, but only the first one survives.
Code references:
1. org.jboss.security.auth.spi.UsernamePasswordLoginModule: Method login():
Object username = sharedState.get("javax.security.auth.login.name");
if (username instanceof Principal) {
identity = (Principal) username;
} else {
String name = username.toString();
try {
identity = createIdentity(name);
} catch (Exception e) {
log.debug("Failed to create principal", e);
throw new LoginException("Failed to create principal: " + e.getMessage());
}
}
The code above checks to see if the Object stored in the shared state is a Principal. This code is correct.
2. Later in the same method:
if (getUseFirstPass() == true) { // Add the username and password to the shared state map
sharedState.put("javax.security.auth.login.name", username);
sharedState.put("javax.security.auth.login.password", credential);
}
This is part of the bug. It stores the name instead of the Object, which causes the second login module to create a new Principal.
3. org.jboss.security.auth.spi.AbstractServerLoginModule: Method: commit():
Principal identity = getIdentity();
principals.add(identity);
'principals' is a Set. The add will not replace an existing identity, so the one created by the second login module is ignored.
If the second login module got the object from the first, it could update it. As it is the second login module cannot do anything with the principal, as it is discarded.
Complications: Some thought would have to be given as to what would happen if two different principal classes were specified in the config. Perhaps disallow that ?
Our specific issue: We have a subclassed SimplePrincipal that holds context based security information for that user that is checked as part of the authorization in our web services. We stack a LDAP login module for the user-id and password, then a subclass of DatabaseServerLoginModule that gets the roles and other context based data from a database.
Work Around: in the subclassed DatabaseServerLoginModule's getRoleSets() method we do:
// To overcome stacked login bugs, we must replace the existing principal
// with a new one created here.
Principal pr = this.getIdentity();
log.trace("SlDbServerLoginModule: getRoleSets(): "
+ "Got Principal from parent: user: " + pr.getName());
SlIdentity slId = new SlIdentity(pr.getName());
slId.addClientList(getSlClientList(username, roleSet));
slId.addSiteList(getSlSiteList(username, roleSet));
Set<Principal> prs = this.subject.getPrincipals();
prs.remove(pr);
prs.add(slId);
log.trace("SlDbServerLoginModule: getRoleSets(): "
+ "Replaced Principal with SlIdentity: user: " + slId.getName());
return roleSets;
Thanks,
Craig.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months