[JBoss JIRA] (JBAS-7210) JBossContextConfig needs to be isolated from the war class loader
by John Chan (JIRA)
[ https://issues.jboss.org/browse/JBAS-7210?page=com.atlassian.jira.plugin.... ]
John Chan commented on JBAS-7210:
---------------------------------
Brad Maxwell, thank you first for your suggestion. But then what is the point of back porting the JBOSS_5_1_0_GA with the fix as mentioned in Bruno Haleblian's comment? Can any one help to build a copy of community version that has the fix?
> JBossContextConfig needs to be isolated from the war class loader
> -----------------------------------------------------------------
>
> Key: JBAS-7210
> URL: https://issues.jboss.org/browse/JBAS-7210
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ClassLoading, Web (Tomcat) service
> Affects Versions: JBossAS-5.1.0.GA
> Reporter: Scott Stark
> Assignee: Scott Stark
> Fix For: 6.0.0.M2
>
> Attachments: jbas-7210.war.zip
>
>
> The parsing of the context.xml by the JBossContextConfig class is using the tccl which causes problems when the war app has tried to load its own xml parser.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (LOGTOOL-71) Allow messages to have expressions resolved at code generation time
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-71?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGTOOL-71:
---------------------------------
Description:
Allow messages in the {{@Message}} annotation to allow expressions in the format of:
{code}
${property.name:default}
{code}
A warning message should be generated if the property name was not found. If not default is found an error should be generated.
The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. There should also be an annotation processing option to allow a path to a properties file.
was:
Allow messages in the {{@Message}} annotation to allow expressions in the format of:
{code}
${property.name:default}
{code}
A warning message should be generated if the property name was not found. If not default is found an error should be generated.
The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime.
> Allow messages to have expressions resolved at code generation time
> -------------------------------------------------------------------
>
> Key: LOGTOOL-71
> URL: https://issues.jboss.org/browse/LOGTOOL-71
> Project: Log Tool
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 1.2.0.Beta1
>
>
> Allow messages in the {{@Message}} annotation to allow expressions in the format of:
> {code}
> ${property.name:default}
> {code}
> A warning message should be generated if the property name was not found. If not default is found an error should be generated.
> The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. There should also be an annotation processing option to allow a path to a properties file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBSER-128) Unable to deserialize Vector when using JDK 7
by Brad Maxwell (JIRA)
Brad Maxwell created JBSER-128:
----------------------------------
Summary: Unable to deserialize Vector when using JDK 7
Key: JBSER-128
URL: https://issues.jboss.org/browse/JBSER-128
Project: JBoss Serialization
Issue Type: Bug
Affects Versions: 1.0.5.FINAL
Environment: JBoss EAP 5.2 on JDK 7
Reporter: Brad Maxwell
Assignee: Clebert Suconic
JDK 7 changed the writeObject of Vector,
ObjectOutputStreamProxy.writeFields is being called, which write the fields out not as a FinalContainer , writeMyself checks the type and for non FinalContainer it just writes the object in metho FieldsContainer.writeField as:
out.writeByte(DataContainerConstants.OBJECTREF);
out.writeObject(value);
When reading, RegularObjectPersister is expecting all FinalContainer.
So it looks like either FinalContainer.writeField may need to wrap the objects in a FinalContainer or on the reading side it needs to read the non wrapped fields before reading the wrapped fields.
public void writeFields() throws IOException {
if (currentContainer!=null)
{
currentContainer.writeMyself(this);
currentContainer=null;
}
JDK 6
--------------------------------------------------------------------------
public class Vector<E>
extends AbstractList<E>
private synchronized void writeObject(java.io.ObjectOutputStream s)
throws java.io.IOException
{
s.defaultWriteObject();
}
JDK 7
--------------------------------------------------------------------------
private void writeObject(java.io.ObjectOutputStream s)
throws java.io.IOException {
final java.io.ObjectOutputStream.PutField fields = s.putFields();
final Object[] data;
synchronized (this) {
fields.put("capacityIncrement", capacityIncrement);
fields.put("elementCount", elementCount);
data = elementData.clone();
}
fields.put("elementData", data);
s.writeFields();
}
org.jboss.serial.exception.SerializationException: Excepted to be int
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readInt(DataContainer.java:1050)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:333)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:290)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:258)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:847)
at test.Serial.main(Serial.java:28)
Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to org.jboss.serial.finalcontainers.IntegerContainer
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readInt(DataContainer.java:1046)
... 7 more
java.io.EOFException
at java.io.DataInputStream.readFully(DataInputStream.java:197)
at org.jboss.serial.util.StringUtil.pullDataToBuffer(StringUtil.java:191)
at org.jboss.serial.util.StringUtil.readString(StringUtil.java:238)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readUTF(DataContainer.java:757)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:322)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:290)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:258)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:363)
at test.Serial.main(Serial.java:48)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBAS-8162) Failed to encode/decode password with name "pinaki" using SecureIdentityLoginModule
by Denis . (JIRA)
[ https://issues.jboss.org/browse/JBAS-8162?page=com.atlassian.jira.plugin.... ]
Denis . commented on JBAS-8162:
-------------------------------
We ran into this issue earlier this week. It's a bug in SecureIdentityLoginModule. The problem is that using BigInteger to convert to and from raw bytes causes the most significant zeros to be dropped. They are not important mathematically (e.g. 023 is same as 23) but they are important cryptographically. In the end it means that exactly 1 of every 256 passwords will not work with JBoss.
I applied the patch below to our systems (the "encoding.length & 7" if statement is new). It doesn't fully address the problem as there's still a 1 in 2^32 chance that a password will not work, but the change is fully backward compatible with the original code.
{noformat}
private static char[] decode(String secret)
throws NoSuchPaddingException, NoSuchAlgorithmException,
InvalidKeyException, BadPaddingException, IllegalBlockSizeException
{
byte[] kbytes = "jaas is the way".getBytes();
SecretKeySpec key = new SecretKeySpec(kbytes, "Blowfish");
BigInteger n = new BigInteger(secret, 16);
byte[] encoding = n.toByteArray();
// reinstate any dropped bytes
if ((encoding.length & 7) != 0) {
final int newLength = ((encoding.length >> 3) + 1) << 3;
byte[] fixedEncoding = new byte[newLength];
for (int i = 1; i < newLength - encoding.length; i++) {
fixedEncoding[i] = 0;
}
System.arraycopy(encoding, 0, fixedEncoding, (newLength - encoding.length), encoding.length);
fixedEncoding[0] = (n.compareTo(BigInteger.ZERO) < 0) ? (byte) -1 : 0;
encoding = fixedEncoding;
}
Cipher cipher = Cipher.getInstance("Blowfish");
cipher.init(Cipher.DECRYPT_MODE, key);
byte[] decode = cipher.doFinal(encoding);
return new String(decode).toCharArray();
}
{noformat}
> Failed to encode/decode password with name "pinaki" using SecureIdentityLoginModule
> -----------------------------------------------------------------------------------
>
> Key: JBAS-8162
> URL: https://issues.jboss.org/browse/JBAS-8162
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-4.2.3.GA
> Environment: Any Operating system
> Reporter: Ravi Sankar
> Assignee: Jesper Pedersen
> Fix For: No Release
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> When trying to encode/decode a password with characters "pinaki" using "SecureIdentityLoginModule" from JBOSS-JCA.JAR, i am getting the following excpetion.
> One of our customers are using this as a password. I am not getting this exception for any other passwords except "pinaki"
> Password After encrption: "-4fb8f7c76b11ab"
> Exception in thread "main" javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
> at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
> at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
> at com.sun.crypto.provider.BlowfishCipher.engineDoFinal(DashoA13*..)
> at javax.crypto.Cipher.doFinal(DashoA13*..)
> at SecureIdentityLoginModule.decode(SecureIdentityLoginModule.java:39)
> at SecureIdentityLoginModule.main(SecureIdentityLoginModule.java:48)
> Please help me to get this issue resolved. Customer is behind me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6635) EJB2 CMB beans: ejbActivate callback is called after the bean creation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6635?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved AS7-6635.
-----------------------------------
Resolution: Won't Fix
Resolving as Won't Fix as CMP support has been removed from upstream AS. The linked bugzilla entry can track this for EAP.
> EJB2 CMB beans: ejbActivate callback is called after the bean creation
> -----------------------------------------------------------------------
>
> Key: AS7-6635
> URL: https://issues.jboss.org/browse/AS7-6635
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Labels: cmp, ejb, entities, entity
>
> Called ejbActive after the create() call on home interface is incorrect by spec.
> 10.1.3
> There are two possible transitions from the pooled to the ready state: through the ejbCreate<METHOD> and ejbPostCreate<METHOD> methods, or through the ejbActivate method. The container invokes the ejbCreate<METHOD> and ejbPostCreate<METHOD> methods when the instance is assigned to an entity object during entity object creation.
> The container invokes the ejbActivate method on an instance when an instance needs to be activated to service an invocation on an existing entity object—this occurs because there is no suitable instance in the ready state to service the client’s call or the ejbTimeout method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6681) ClusteredSingleSignOn ClassCastException with non-distributable apps
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6681?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6681:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 920367|https://bugzilla.redhat.com/show_bug.cgi?id=920367] from POST to MODIFIED
> ClusteredSingleSignOn ClassCastException with non-distributable apps
> --------------------------------------------------------------------
>
> Key: AS7-6681
> URL: https://issues.jboss.org/browse/AS7-6681
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Dennis Reed
> Assignee: Dennis Reed
> Fix For: 8.0.0.Alpha1
>
> Attachments: test.war
>
>
> When ClusteredSingleSignOn is enabled, and a user has an active session in a non-distributable web application, invalidating any session in the same SSO from a different AS instance in the cluster causes the following exception (logged numerous times in various ways):
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-20,null) ISPN000136: Execution error: org.infinispan.CacheException: Caught exception [java.lang.ClassCastException] while invoking method [public void org.jboss.as.clustering.web.sso.infinispan.SSOClusterManager.cacheEntryRemoved(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] on listener instance: org.jboss.as.clustering.web.sso.infinispan.SSOClusterManager@28e13c84
> ...
> Caused by: java.lang.ClassCastException: org.apache.catalina.session.StandardSession cannot be cast to org.jboss.as.web.session.ClusteredSession
> at org.jboss.as.web.sso.ClusteredSingleSignOn.deregisterLocal(ClusteredSingleSignOn.java:523) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months