[JBoss JIRA] Created: (JBREM-971) Enhance client-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded
by Ovidiu Feodorov (JIRA)
Enhance client-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded
---------------------------------------------------------------------------------------------------------------------------
Key: JBREM-971
URL: http://jira.jboss.com/jira/browse/JBREM-971
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP7
Reporter: Ovidiu Feodorov
Assigned To: Ovidiu Feodorov
Priority: Minor
A SSL connection (for example) may fail due to handshake problems, but Remoting would discard the original exception and throw a different and less relevant exception, thus hiding the original cause of the error.
Example:
The server reports
Caused by: java.net.SocketException: Socket Closed
at java.net.PlainSocketImpl.setOption(Unknown Source)
at java.net.Socket.setSoTimeout(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(Unknown Source)
at org.jboss.remoting.transport.socket.SocketWrapper.setTimeout(SocketWrapper.java:85)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:168)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
while in fact the root problem is:
14:39:38,174 ERROR [STDERR] javax.net.ssl.SSLException: Received fatal alert: internal_error
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1657)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
14:39:38,175 ERROR [STDERR] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
This makes troubleshooting of a potential simple problem such a misspelled truststore file name laborious and time consuming.
The server-side code could be modified to log relevant exceptions.
--
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
17 years, 8 months
[JBoss JIRA] Created: (JBRULES-1566) Documentation on update()
by Steve Miner (JIRA)
Documentation on update()
-------------------------
Key: JBRULES-1566
URL: http://jira.jboss.com/jira/browse/JBRULES-1566
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation
Affects Versions: 4.0.6
Environment: HTML doc
Reporter: Steve Miner
Assigned To: Mark Proctor
Priority: Minor
in section 6.5.3. The Right Hand Side (then)
...
"update(object, handle);" will tell the engine that an object has changed (one that has been bound to something on the LHS) and rules may need to be reconsidered.
Actually, update(object) will work most of the time. And update(handle, object) is appropriate when you want to replace the object with a new one. Notice the order of the arguments. (Java)
--
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
17 years, 8 months
[JBoss JIRA] Commented: (EJBTHREE-572) PersistenceUnitInfo.getNewTempClassLoader()
by Michael O'Brien (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-572?page=comments#action_12411684 ]
Michael O'Brien commented on EJBTHREE-572:
------------------------------------------
Hi,
The following workaround has been checked in for EclipseLink M8 to work with JBoss 4.2.2 GA.
Container managed entities should predeploy/deploy and register now with/without static weaving.
When the UCL3 classLoader no longer causes a NPE we will reenable dynamic weaving on EAR predeploy().
http://bugs.eclipse.org/229634
Workaround:
---------------------------------
EclipseLink will use the non-temporary classLoader instead of the one from getNewTempClassLoader() obtained from the JBoss PersistenceUnitInfo that throws a NPE on loadClass() or Class.forName().
We require that JBoss implementers statically weave container managed entities and reference JBoss as the target-server in persistence.xml.
Deployment Changes:
1) If weaving is required then static weave the entities before EAR packaging using either the command-line weaver or the weaving ant task.
2) All persistence units deployed to the JBoss container must contain the following property in persistence.xml or container managed entities will predeploy but fail to be managed at runtime.
<property
name="eclipselink.target-server"
value="org.eclipse.persistence.platform.server.jboss.JBossPlatform"/>
JBoss AS 4.2.2 GA debugging:
----------------------------------------------------------
I debugged the UCL3 NullPointerException into the JBoss AS 4.2.2 GA source into the following segment of code.
In the following function the classloader parent tree is searched all the way to the root.
no clazz is returned and in the finally clause the last log.trace causes a RuntimeException on a NPE.
Curious though that the line number in Logger.trace() does not correspond to the JDK 1.5 src.
package org.jboss.mx.loading
public abstract class RepositoryClassLoader extends URLClassLoader
public Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
boolean trace = log.isTraceEnabled();
if (trace)
log.trace("loadClass " + this + " name=" + name+", loadClassDepth="+loadClassDepth);
Class clazz = null;
try
{
if (repository != null)
{
clazz = repository.getCachedClass(name);
if (clazz != null)
{
if( log.isTraceEnabled() )
{
StringBuffer buffer = new StringBuffer("Loaded class from cache, ");
ClassToStringAction.toString(clazz, buffer);
log.trace(buffer.toString());
}
return clazz;
}
}
clazz = loadClassImpl(name, resolve, Integer.MAX_VALUE);
return clazz;
}
finally
{
if (trace)
{
if (clazz != null)
log.trace("loadClass " + this + " name=" + name + " class=" + clazz + " cl=" + clazz.getClassLoader());
else
--->NPE log.trace("loadClass " + this + " name=" + name + " not found");
}
}
}
Thread [main] (Suspended)
UnifiedClassLoader3(RepositoryClassLoader).loadClass(String, boolean) line: 425
UnifiedClassLoader3(ClassLoader).loadClass(String) line: 251
UnifiedClassLoader3(ClassLoader).loadClassInternal(String) line: 319
Class<T>.forName0(String, boolean, ClassLoader) line: not available [native method]
Class<T>.forName(String, boolean, ClassLoader) line: 242
PrivilegedAccessHelper.getClassForName(String, boolean, ClassLoader) line: 85
XMLEntityMappings.getClassForName(String, ClassLoader) line: 120
XMLEntityMappings.getClassForName(String) line: 157
XMLEntityMappings.initPersistenceUnitClasses() line: 389
MetadataProcessor.initPersistenceUnitClasses() line: 188
MetadataProcessor.processEntityMappings() line: 298
Results:
--------
15:41:43,772 INFO [STDOUT] [EPS Warning]: 2008.05.02 15:41:43.755--Thread(Thread[main,5,jboss])--The temporary classLoader for PersistenceLoadProcessor [helloworld] is not available. Switching classLoader to [org.jboss.mx.loading.UnifiedClassLoader3@18b995c{ url=file:/C:/opt/jboss422/server/default/tmp/deploy/tmp13465jsfejb3.ear ,addedOrder=45}]. Weaving has been disabled for this session. EclipseLink may be unable to get a spec mandated temporary class loader from the server, you may be able to use static weaving as an optional workaround.
15:41:44,221 INFO [JmxKernelAbstraction] installing MBean: jboss.j2ee:ear=jsfejb3.ear,jar=app.jar,name=TodoDao,service=EJB3 with dependencies:
15:41:44,221 INFO [JmxKernelAbstraction] persistence.units:ear=jsfejb3.ear,jar=app.jar,unitName=helloworld
15:41:44,359 INFO [EJBContainer] STARTED EJB: TodoDao ejbName: TodoDao
15:42:45,344 INFO [STDOUT] [EPS Finer]: 2008.05.02 15:42:45.343--UnitOfWork(20862427)--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--TX binding to tx mgr, status=STATUS_ACTIVE
15:42:45,344 INFO [STDOUT] [EPS Finest]: 2008.05.02 15:42:45.344--UnitOfWork(20862427)--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--Execute query DoesExistQuery()
15:42:45,350 INFO [STDOUT] [EPS Finest]: 2008.05.02 15:42:45.350--UnitOfWork(20862427)--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--PERSIST operation called on: Todo@15914f3.
thank you
/michael
> PersistenceUnitInfo.getNewTempClassLoader()
> -------------------------------------------
>
> Key: EJBTHREE-572
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-572
> Project: EJB 3.0
> Issue Type: Bug
> Reporter: Emmanuel Bernard
> Assigned To: Ales Justin
>
> The sooner the better.
> Hibernate can't enhance the classes to make property (not association) lazy loading.
> Toplink just can't start.
> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3939615#3939615
--
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
17 years, 8 months
[JBoss JIRA] Created: (JBRULES-1583) Heap and scheduled Activations
by s s (JIRA)
Heap and scheduled Activations
------------------------------
Key: JBRULES-1583
URL: http://jira.jboss.com/jira/browse/JBRULES-1583
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.4
Environment: Windows XP / Eclipse Europa / Java 1.5 / drools 4.0.4
Reporter: s s
Assigned To: Mark Proctor
Hi everyone,
I've wrote that rule:
rule "COMPTEUR"
duration 10000
when
$alarme : Alarm ();
then
$alarme.increment();
update($alarme);
end
Using JProfile, I've noticed that PropagationContextImpl was constantly growing
in the heap. Then, I looked the scheduled activations and saw that some
scheduledExecutionTime was expired. So, I wrote this code to purge the expired
activations:
Activation[] activations = session.getAgenda().getScheduledActivations();
long now = (new Date()).getTime();
for(int i=0;i<activations.length;i++){
if( now >
((org.drools.common.ScheduledAgendaItem)activations[i]).scheduledExecutionTime()){
activations[i].remove();
}
}
Now, the heap isn't growing anymore but what are the consequences of doing
something like that? So far, there are no noticeable regression on my
application.
Thanks for your help.
--
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
17 years, 8 months
[JBoss JIRA] Commented: (HIBERNATE-83) Create release notes for Hibernate
by Gail Badner (JIRA)
[ http://jira.jboss.com/jira/browse/HIBERNATE-83?page=comments#action_12411673 ]
Gail Badner commented on HIBERNATE-83:
--------------------------------------
I've documented expected test failures and the flag to ignore expected failues in : https://svn.jboss.org/repos/hibernate/core/branches/Branch_3_2_4_SP1_CP/r...
In addition, there should be something in the release notes like:
"It is recommended that the Hibernate unit tests be executed using the same dialect and version of JDBC that will be used in production, to ensure that the configuration setting, hibernate.jdbc.batch_versioned_data, is set properly. The value for hibernate.jdbc.batch_versioned_data determines if Hibernate will use batches for updating versioned data (an optimization).
Optimistic locking relies on the ability to obtain the number of rows updated. If the JDBC driver does not return update counts for each command in a batch, then hibernate.jdbc.batch_versioned_data should be set to "false".
The unit tests use the settings in etc/hibernate.properties. The value for hibernate.jdbc.batch_versioned_data is set to "true" in that file. If the unit tests involving optimistic locking fail, then the appropriate value for this flag is "false".
Some versions of Oracle JDBC do not support returning update counts for each command in a batch, so it is particularly important to test using the same version of JDBC as will be used in production."
Also, for the migration section:
"OracleDialect and Oracle9Dialect have been deprecated. Oracle8iDialect, Oracle9iDialect, or Oracle10gDialect should be used instead."
> Create release notes for Hibernate
> ----------------------------------
>
> Key: HIBERNATE-83
> URL: http://jira.jboss.com/jira/browse/HIBERNATE-83
> Project: Hibernate
> Issue Type: Task
> Reporter: Gail Badner
> Assigned To: Bawany Satgunanathan
>
> Create release notes for the standalone application that includes:
> 1) expected unit test failures
> 2) if "non-supported" dependencies are not included in the distribution, then unit tests using those dependencies will fail out of the box; this should be documented
> 3) JDK 1.4 is not supported; no testing done using JDK 1.4; only JDK 1.5 is supported
> Does anything else need to be put in the release notes for the standalone product?
> Should there be release notes for Hibernate embedded in EAP?
--
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
17 years, 8 months
[JBoss JIRA] Created: (JBRULES-1569) Can't use "this" keyword in MVEL dialect
by Michael Neale (JIRA)
Can't use "this" keyword in MVEL dialect
----------------------------------------
Key: JBRULES-1569
URL: http://jira.jboss.com/jira/browse/JBRULES-1569
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.6
Reporter: Michael Neale
Assigned To: Mark Proctor
Fix For: 5.0.0-M1
rule "Gold Discount"
dialect "mvel"
when
#conditions
order : OrderHeader()
customer : Customer()
Customer( this == customer, status >= "10" && < "50" ) or OrderHeader( this == order, netAmount >= "50" && < "100" )
then
#actions
order.setOrderDiscount(6.0);
System.out.println("order discount for customer: " + customer.getUserName() + " is " + order.getOrderDiscount());
end
will fail due to the "this == order" - this means something else in MVEL.
--
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
17 years, 8 months