[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1279) shutdown -u -p
[ http://jira.jboss.com/jira/browse/JBAS-1279?page=comments#action_12314617 ] Wonne Keysers commented on JBAS-1279: - Thanks! It might be even more interesting to let the Shutdown class ask for a password when only `shutdown.sh -S -u admin` is invoked? shutdown -u -p -- Key: JBAS-1279 URL: http://jira.jboss.com/jira/browse/JBAS-1279 Project: JBoss Application Server Type: Feature Request Versions: JBossAS-4.0.1 Final Reporter: Wonne Keysers Assignee: Scott M Stark Fix For: JBossAS-4.0.2RC1 This feature does work in 3.2.x, but is apparently not yet implemented in 4.0.1 ? Unable to shutdown the server when the following is commented out in jmx-invoker-service.xml: descriptors interceptors interceptor code=org.jboss.jmx.connector.invoker.AuthenticationInterceptor securityDomain=java:/jaas/jmx-console/ /interceptors /descriptors -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBPM-58) persistence
persistence --- Key: JBPM-58 URL: http://jira.jboss.com/jira/browse/JBPM-58 Project: JBoss jBPM Type: Task Components: Core Engine Reporter: Tom Baeyens Assigned to: Tom Baeyens Priority: Minor 1) how to delete process instances and process definitions : cascading deletes ? 2) long or Long for id's. is there a preference. i have experienced some problems with the null-value not being interpreted as i had hoped in case of long but that might be my ignorance. 3) query tokens and/or process instances based on process variables. how to query the -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: Exception on hot re-deploy of EAR using JBossCache
Thanks for the answer. Is there something that I am doing wrong in my package to cause this issue? This is happening upon the re-deploy of the EAR, so I am wondering why the re-deploy is using a destroyed class loader instead of a new one. Any suggestions on how I might fix it or is the JBoss restart the only way to go? Thanks. Thomas View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861533#3861533 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861533 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1281) JCA Resource is not undeployed
JCA Resource is not undeployed -- Key: JBAS-1281 URL: http://jira.jboss.com/jira/browse/JBAS-1281 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-4.0.1 Final Environment: Java version: 1.5.0,Sun Microsystems Inc. Java VM: Java HotSpot(TM) Server VM 1.5.0-b64,Sun Microsystems Inc. OS-System: Linux 2.4.21-4.EL,i386 Reporter: Michael Kopp Assigned to: Scott M Stark Priority: Minor I originally reported this at the sourceforge tracking system. Bug Entry: http://sourceforge.net/tracker/?group_id=22866atid=376685func=detailaid=1070345 Topic Entry: http://www.jboss.org/index.html?module=bbop=viewtopict=56558 It was closed and said to be fixed in 4.0.1RC2. I now open it again here as the problem still persists in 4.0.1 final. I have three rar archives in my application, each of them leaves the management bean: J2EEApplication=ftisoft.app.ear,J2EEServer=Local,ResourceAdapterModule=ftisoft.engine.rar,j2eeType=ResourceAdapter,name=Engine Adapter J2EEApplication=ftisoft.app.ear,J2EEServer=Local,ResourceAdapterModule=ftisoft.filesystem.rar,j2eeType=ResourceAdapter,name=FTI Filesystem Adapter J2EEApplication=ftisoft.app.ear,J2EEServer=Local,ResourceAdapterModule=ftisoft.translator.rar,j2eeType=ResourceAdapter,name=MSF Translation Adapter I have two (configured) instances of the filesystem adapter and only one them leaves: J2EEServer=Local,JCAResource=ftisoft/adapters/filesystem/ftp,j2eeType=JCAConnectionFactory,name=ftisoft/adapters/filesystem/ftp J2EEServer=Local,ResourceAdapter=FTI Filesystem Adapter,j2eeType=JCAResource,name=ftisoft/adapters/filesystem/ftp J2EEServer=Local,j2eeType=JCAManagedConnectionFactory,name=ftisoft/adapters/filesystem/ftp I cannot see why. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1281) JCA Resource is not undeployed
[ http://jira.jboss.com/jira/browse/JBAS-1281?page=history ] Michael Kopp updated JBAS-1281: --- Attachment: server.log I extracted the interessting part of the server log JCA Resource is not undeployed -- Key: JBAS-1281 URL: http://jira.jboss.com/jira/browse/JBAS-1281 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-4.0.1 Final Environment: Java version: 1.5.0,Sun Microsystems Inc. Java VM: Java HotSpot(TM) Server VM 1.5.0-b64,Sun Microsystems Inc. OS-System: Linux 2.4.21-4.EL,i386 Reporter: Michael Kopp Assignee: Scott M Stark Priority: Minor Attachments: server.log I originally reported this at the sourceforge tracking system. Bug Entry: http://sourceforge.net/tracker/?group_id=22866atid=376685func=detailaid=1070345 Topic Entry: http://www.jboss.org/index.html?module=bbop=viewtopict=56558 It was closed and said to be fixed in 4.0.1RC2. I now open it again here as the problem still persists in 4.0.1 final. I have three rar archives in my application, each of them leaves the management bean: J2EEApplication=ftisoft.app.ear,J2EEServer=Local,ResourceAdapterModule=ftisoft.engine.rar,j2eeType=ResourceAdapter,name=Engine Adapter J2EEApplication=ftisoft.app.ear,J2EEServer=Local,ResourceAdapterModule=ftisoft.filesystem.rar,j2eeType=ResourceAdapter,name=FTI Filesystem Adapter J2EEApplication=ftisoft.app.ear,J2EEServer=Local,ResourceAdapterModule=ftisoft.translator.rar,j2eeType=ResourceAdapter,name=MSF Translation Adapter I have two (configured) instances of the filesystem adapter and only one them leaves: J2EEServer=Local,JCAResource=ftisoft/adapters/filesystem/ftp,j2eeType=JCAConnectionFactory,name=ftisoft/adapters/filesystem/ftp J2EEServer=Local,ResourceAdapter=FTI Filesystem Adapter,j2eeType=JCAResource,name=ftisoft/adapters/filesystem/ftp J2EEServer=Local,j2eeType=JCAManagedConnectionFactory,name=ftisoft/adapters/filesystem/ftp I cannot see why. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head build.688 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050111033152Lbuild.688 BUILD COMPLETE-build.688Date of build:01/11/2005 03:31:52Time to build:35 minutes 30 secondsLast changed:01/11/2005 02:49:28Last log entry:switched id generator to TableGenerator to test new TableGenerator handling Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(10)1.3modifiedricharzkejb3/src/test/org/jboss/ejb3/test/entity/Flight.javaswitched id generator to TableGenerator to test new TableGenerator handling1.18modifiedricharzkejb3/src/main/org/jboss/ejb3/entity/EntityToHibernateXml.javapartly implemented handling of TableGenerator annotation1.1addedricharzkejb3/src/main/org/jboss/ejb3/entity/JTATableIdGenerator.javainitial commit, TODO sequence allocation1.1addedtelrodremoting/tests/src/org/jboss/remoting/transport/http/ComplexObject.javaJBREM-16: HTTP server invoker implemented, along with tests (still needs cleanup though).1.1addedtelrodremoting/tests/src/org/jboss/remoting/transport/http/HTTPInvokerTestClient.javaJBREM-16: HTTP server invoker implemented, along with tests (still needs cleanup though).1.1addedtelrodremoting/tests/src/org/jboss/remoting/transport/http/HTTPInvokerTestServer.javaJBREM-16: HTTP server invoker implemented, along with tests (still needs cleanup though).1.4modifiedtelrodremoting/src/main/org/jboss/remoting/ServerInvocationHandler.javaJBREM-16: HTTP server invoker implemented, along with tests (still needs cleanup though).1.4modifiedtelrodremoting/src/main/org/jboss/remoting/transport/http/HTTPServerInvoker.javaJBREM-16: HTTP server invoker implemented, along with tests (still needs cleanup though).1.2modifiedtelrodremoting/src/main/org/jboss/remoting/marshal/http/HTTPUnMarshaller.javaJBREM-16: HTTP server invoker implemented, along with tests (still needs cleanup though).1.2modifiedtelrodremoting/src/main/org/jboss/remoting/marshal/http/HTTPMarshaller.javaJBREM-16: HTTP server invoker implemented, along with tests (still needs cleanup though).
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1282) Fallback to message-destination-type
Fallback to message-destination-type Key: JBAS-1282 URL: http://jira.jboss.com/jira/browse/JBAS-1282 Project: JBoss Application Server Type: Feature Request Components: EJBs Versions: JBossAS-4.0.1 Final Environment: Java version: 1.5.0,Sun Microsystems Inc. Java VM: Java HotSpot(TM) Server VM 1.5.0-b64,Sun Microsystems Inc. OS-System: Linux 2.4.21-4.EL,i386 Reporter: Michael Kopp Assigned to: Scott M Stark Priority: Trivial I have two MDB's that have no activation config. They actually don't need one as the only relevant information is the destination type which is already stated in the message-destination-type tag. Nevertheless I get the following message for these two MDB's: No message-driven-destination given; using; guessing type When I add the activation-config this message vanishes. Therefore I suggest to use the message-destination-type in case the 'destinationType' property is not present in the activation config (or the activation config is missing). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBMICROCONT-5) Main Deployer
[ http://jira.jboss.com/jira/browse/JBMICROCONT-5?page=history ] Dimitris Andreadis reassigned JBMICROCONT-5: Assign To: Dimitris Andreadis Main Deployer - Key: JBMICROCONT-5 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-5 Project: JBoss MicroContainer Type: Task Components: Deployment Reporter: Adrian Brock Assignee: Dimitris Andreadis Fix For: JBossMC_1_0_0M2 MainDeployer The primary methods of MainDeployer are (re/un)deploy(URL) other methods are (un)register/register(deployer, priority) which will be used by the microcontainer when a deployer is installed stats based methods that expose information from the VDF and config/constructors methods for things like the VDF and initial deployers. deploy(url) 1) create a skeleton VDF context for the top level deployment 2) ask the structural component chain who recognises it repeat recursively for identified subcontexts 3) invoke down the deployment component chain starting with the deepest subcontexts first redeploy(url) similar to deploy() but performing a reinstall on the microcontainer (i.e. suspend on valve for components being reinstalled) undeploy(url) invoke down the deployment chain in reverse order to remove the installed components Reverse order means both in terms of subcontexts and priority. (un)register/register(deployer) The deployer here identifies the structural and deployment components of the deployer and their respective priorities. This will be the name in the registry which might be instantiated later. Where present, the deployer is added to the relevent chain. ISSUE: Need to tighten up the semantics of the register/unregister(deployer) for when the deployment component has dependencies and cannot be instantiated immediately -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head build.689 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050111053753Lbuild.689 BUILD COMPLETE-build.689Date of build:01/11/2005 05:37:53Time to build:44 minutes 15 secondsLast changed:01/11/2005 05:00:32Last log entry:fixed complex type unmarshalling tests (one still fails, probably, because xsd type is not available during parsing) Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(3)1.3modifiedloubyanskywebservice/test/java/org/jboss/test/ws/jaxb/ComplexTypeUnmarshallerTestCase.javafixed complex type unmarshalling tests (one still fails, probably, because xsd type is not available during parsing)1.7modifiedloubyanskywebservice/src/main/org/jboss/ws/jaxb/UnmarshallerImpl.javajaxb unmarshaller implementation1.16modifiedloubyanskycommon/src/main/org/jboss/xml/binding/MappingObjectModelFactory.javatry to find and use Field object if setter/getter Methods are not found for a field
[JBoss-dev] [JBoss JIRA] Created: (JGRP-24) ChannelClosedException does not always reconnect correctly
ChannelClosedException does not always reconnect correctly
--
Key: JGRP-24
URL: http://jira.jboss.com/jira/browse/JGRP-24
Project: JGroups
Type: Bug
Environment: Fedora Linux. JDK 1.4
Reporter: Tarek Hammoud
Assigned to: Bela Ban
Version JGroups 2.2.7
When a ChannelClosedException is encountered (legit
reasons), the sleep(1000) code below causes a race
condition which results in PullPushAdapter ignoring any
new messages.
The JChannel code calls the channelReconnected before
the sleep(1000) returns. This causes the
channelReconnected method to skip calling the start()
method. When the code after sleep() executes, the
receiver_thread is set to back to null thus causing
messages to be thrown out. Our workaround was to remove
the sleep code.
From PullPushAdapter.java:
public void channelReconnected(Address addr) {
if(receiver_thread == null)
start();
}
and
catch(ChannelClosedException closed_ex) {
// The sleep will cause problems if the channel
reconnects in under 1000 mills.
Util.sleep(1000);
receiver_thread=null;
break;
Thank you.
Add a Comment
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Portal] - Re: Adding personal portlet in jboss portal
Hi, Thanks for that - I can see the forums app has been built into a SAR file for deployment with a WAR of JSP+resources inside that. That looks ok - but how then do I access it? I assume if I reference the forums portlet instance from the default-portal.xml in the nukes-core.WAR then it will fail to initialise it because it's not deployed as part of the same distribution...? i.e. do i need to include the forums WAR fail into the main nukes SAR for it to work? Cheers, Kev View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861570#3861570 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861570 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Portal] - Re: Adding personal portlet in jboss portal
no it will not fail if you specify a window in -portal.xml. Usually a window depends on a portal and an instance. The instance in its turn depends on a deployed portlet. JBoss Portal has been build in the mind that not all the components may be present at runtime. So for JBoss Portal window = portal + instance. If you remove either the portal or the instance, the window will still be there but waiting that all the components it depends on are valid. I will commit soon another deployment format : -page.xml, with that you can specify pages separately and hook them into an existing portal. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861572#3861572 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861572 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1275) JDK 1.3 OME running the testsuite
[ http://jira.jboss.com/jira/browse/JBAS-1275?page=history ] Scott M Stark updated JBAS-1275: Attachment: jboss-all-config-tests_gc.log I ran the jboss-all-config-tests using jdk1.5.0_01: [EMAIL PROTECTED] testsuite]$ ant -Dnojars=t jboss-all-config-tests ... and tracked its permanent space using jstat. The jboss-all-config-tests_gc.log attachment is the result, and I see the PU go from 19782.2 at the start to 43921.7 at the end. So the permanent space is definitely growing, but its not approaching the levels apparently needed by jdk1.3.1. JDK 1.3 OME running the testsuite - Key: JBAS-1275 URL: http://jira.jboss.com/jira/browse/JBAS-1275 Project: JBoss Application Server Type: Bug Components: Test Suite Versions: JBossAS-3.2.7 Final Environment: [EMAIL PROTECTED] bin]$ $JAVA_HOME/bin/java -version java version 1.3.1_14 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_14-b03) Java HotSpot(TM) Client VM (build 1.3.1_14-b03, mixed mode) Reporter: Scott M Stark Assignee: Clebert Suconic Fix For: JBossAS-3.2.7 Final Attachments: jboss-all-config-tests_gc.log, jboss-testsuite-analysis.txt Time Spent: 1 day, 1 hour Remaining: 0 minutes When running the jboss-all-config-tests I have been seeing OutOfMemoryErrors well into the tests, but -verbose:gc clearly shows that there is plenty of memory. The process views also show that the handle/thread count is fine. That pretty much only left the MaxPermSize as becoming full, and I was able to run the tests using: JAVA_OPTS=-verbose:gc -XX:MaxPermSize=70m -Xmx128m This seems like an excessive amount of perm heap memory so I would like to look into this further. This does not happen when running JDK 1.4.2. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Other JBoss Development Design] - dom4j or jaxp ?
in JBoss jBPM we want to use xml dom trees and xpath expression handling. afaik, j2se 1.4 includes jaxp 1.1 (no xpath expression handling) j2ee 1.4 includes jaxp 1.2 j2se 1.5 includes jaxp 1.3 (includes xpath expressions) my initial idea is to use jaxp domtrees and jaxen for the xpath expressions. this requires 200KB of libs (jaxen) and runs on java 1.4. if we would drop support for 1.4 in the future, we could change the xpath usage to jaxp, removing even the dependency on jaxen. or does anyone see reason for still using dom4j ? other opinions ? regards, tom. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861593#3861593 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861593 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: Revising the project structure
The example in the diagram illustrates that components will be extacted from the source tree. Certainly, aop cache make sense as standalone components. The question is, how far do we want to take this? Do we want to extract all components into their own projects? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861597#3861597 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861597 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
You'll have to show me why it is easier. Take the pathological case: 1) A bean is requested to be deployed that has the security annotation, BUT the bean class is not deployed yet so we don't this yet. 2) When the bean class is deployed it then knows it needs to add the aspect and metadata, but the aspect class is not deployed yet. It does know enough to add the metadata to construct the aspect once the class is available. 3) The aspect class is deployed we can look at it and see whether it has other dependency injections. etc... Once all dependencies are satisfied it can then fully construct the aspect, meaning it can construct the container which in turn means the bean is now fully deployed. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861602#3861602 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861602 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Eclipse IDE (dev)] - Re: problem with th Jboss-IDE tutorial
use java perspective. and read general FAQ sections before posting View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861604#3861604 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861604 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - [CacheStoreInterceptor]failed committing transaction to cach
Hi, I am working with jbosscache 1.2 and jboss 4.0.1 and I got the following message everytime I get a node from the cache and don't put anyone. [CacheStoreInterceptor] failed committing transaction to cache loader | java.lang.Exception: transaction null:2 not found in transaction table | at org.jboss.cache.loader.FileCacheLoader.commit(FileCacheLoader.java:195) | at org.jboss.cache.interceptors.CacheStoreInterceptor$SynchronizationHandler.afterCompletion(CacheStoreInterceptor.java:251) The problem dissapears when I put (with put method) a node before doing a get. It seems a transaction problem. Does any body know what happens? Thanks all. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861608#3861608 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861608 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: Revising the project structure
I think we can extract pretty much any root directory under the jboss tree (and probably should). This would start with common (as you noted in your diagram) and go from there (since common should not have any other module that it depends on). Hopefully we won't have any circular dependancies (which would cause a build problem now anyways). View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861609#3861609 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861609 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assigned to: Scott M Stark See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
You can see earlier on in this thread I used joinPoint.getMetaData() I have not been arguing against it. I am arguing against having getMetaData() and getAnnotation() there should be one api (which might be neither or a combination of these) unless there is good reason otherwise. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861603#3861603 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861603 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1284) SOAP SAAJ JBOSS implementation attachments bug
SOAP SAAJ JBOSS implementation attachments bug -- Key: JBAS-1284 URL: http://jira.jboss.com/jira/browse/JBAS-1284 Project: JBoss Application Server Type: Bug Components: Web Services service Versions: JBossAS-4.0.1 Final Environment: Windows-XP SP2 Reporter: Frank Balba Assigned to: Scott M Stark Using JBOSS-SAAJ implementation, no attachments could get through within a SOAP message. Creating attachments and adding them to a SOAP message will result a fine SOAP message on the client side however once it arrives to a dedicated servlet the received attachmentpart returns 'null' for attachmentPart.getContentType(). Using another SAAJ package (not the one included with JBOSS 4.0.1) eliminates this problem. Frank -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1284) SOAP SAAJ JBOSS implementation attachments bug
[ http://jira.jboss.com/jira/browse/JBAS-1284?page=comments#action_12314624 ] Anil Saldhana commented on JBAS-1284: - WS-I Basic Profile does not endorse Soap with Attachments. Since the goal of v4.0 in JBoss was J2EE 1.4 compliance, we had to comply with WS-I BP. Hence there is currrently no support for SwA in JBoss v4.0.1. But given that, we are working on providing SwA in the near future. Please check http://jira.jboss.com/jira/browse/JBWS-46 SOAP SAAJ JBOSS implementation attachments bug -- Key: JBAS-1284 URL: http://jira.jboss.com/jira/browse/JBAS-1284 Project: JBoss Application Server Type: Bug Components: Web Services service Versions: JBossAS-4.0.1 Final Environment: Windows-XP SP2 Reporter: Frank Balba Assignee: Scott M Stark Using JBOSS-SAAJ implementation, no attachments could get through within a SOAP message. Creating attachments and adding them to a SOAP message will result a fine SOAP message on the client side however once it arrives to a dedicated servlet the received attachmentpart returns 'null' for attachmentPart.getContentType(). Using another SAAJ package (not the one included with JBOSS 4.0.1) eliminates this problem. Frank -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=history ] Jeremy Brown updated JBAS-1283: --- Attachment: test.war Test war file which exhibits behavior. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Scott M Stark Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=history ] Anil Saldhana updated JBAS-1283: Priority: Minor (was: Major) This is not a major issue. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Scott M Stark Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1275) JDK 1.3 OME running the testsuite
[ http://jira.jboss.com/jira/browse/JBAS-1275?page=comments#action_12314628 ] Clebert Suconic commented on JBAS-1275: --- For generating CorrectAnalysis-jvm14.permanentCapacity.txt I've used this line command: jstat -gcpermcapacity 3224 5s CorrectAnalysis-jvm14.permanentCapacity.txt Note that JBoss was running into JVM 1.4.2 with the Hotspot instrumentation active (-XX:+UsePerfData according to http://java.sun.com/performance/jvmstat/) I used jstat provided by JDK 5.0 against the process without any problems. JDK 1.3 OME running the testsuite - Key: JBAS-1275 URL: http://jira.jboss.com/jira/browse/JBAS-1275 Project: JBoss Application Server Type: Bug Components: Test Suite Versions: JBossAS-3.2.7 Final Environment: [EMAIL PROTECTED] bin]$ $JAVA_HOME/bin/java -version java version 1.3.1_14 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_14-b03) Java HotSpot(TM) Client VM (build 1.3.1_14-b03, mixed mode) Reporter: Scott M Stark Assignee: Clebert Suconic Fix For: JBossAS-3.2.7 Final Attachments: CorrectAnalysis-jvm14.permanentCapacity.txt, jboss-all-config-tests_gc.log, jboss-testsuite-analysis.txt Time Spent: 1 day, 1 hour Remaining: 0 minutes When running the jboss-all-config-tests I have been seeing OutOfMemoryErrors well into the tests, but -verbose:gc clearly shows that there is plenty of memory. The process views also show that the handle/thread count is fine. That pretty much only left the MaxPermSize as becoming full, and I was able to run the tests using: JAVA_OPTS=-verbose:gc -XX:MaxPermSize=70m -Xmx128m This seems like an excessive amount of perm heap memory so I would like to look into this further. This does not happen when running JDK 1.4.2. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
Bill, we are going in circles. You asked me to show you where this metadata is defined in the current xml It is not, that is what we are discussing how to do here. That was my question earlier in the thread. You say the aspect needs to get metadata from the bean class/joinpoint. I agree, that is the purpose of describe. Again annotations aren't implemented in my prototype. What I'm trying to understand is why we need two apis to get metadata at runtime. I haven't since a convincing argument for this so I will assume there isn't one. Let's take a trivial example: Somebody says they want to deploy a bean: They also want a container. There are two ways to do this. 1) They explicity wrap it in a container, either using xml or programatic definition of the equivalent bean metadata (see examples earlier). This is the long winded approach for people who want total control of what is happening (5% of cases). 2) The SAME metadata comes from the DESCRIBE stage. i.e. when it loads the class it discovers there are annotations and augments the metadata. i.e. it adds the metadata and interceptors into the container definition. Maybe it even adds a container to the definition if one wasn't present. This is what most people will use (95% of cases). Later, the aspect will use getMetaData() to retrieve this information. There is also a hybrid approach where there maybe both tags on the class and metadata already present in the bean metadata - e.g. the xml override of annotations. What I'm trying to get to is what changes do we need to plug in JBoss AOP into the MC. My conclusions so far are: 1) We need to remove all notion of container from MC. We discussed this on a different thread. 2) We need to add to the DESCRIBE stage of the MC to allow a hook where a container can be plugged. It will register back additional bean metadata like what aspects needs constructing, what metadata is present and whether these have dependencies. I see this more as a container factory since I want it to describe to MC what needs constructing using Bean MetaData rather trying to create the container objects. annotations - BeanMetaData Letting the container factory create the container directly may not be possible because other dependencies are not satisifed (classloading, jndi binding or just plain IOC dependency). 3) The user has the option to use their own container metadata definition (long winded metadata description) to get exactly what they want rather than using the container factory. This is transparent to the MC since all it sees is Bean MetaData to contruct the container objects in the correct order. 4) We need to consider a mixture of (2) and (3) where the user wants to override what is coming from the class annotations, e.g. add an aspect, change a metadata config, etc. In (3) this may not even be an AOP container. But to take advantage of JBoss aspects it needs to follow our container spi that defines the join points/invocation/etc. Using the AOP container gives a lot more functionality than say a simple Proxy container. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861629#3861629 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861629 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
[EMAIL PROTECTED] wrote : You'll have to show me why it is easier. | | Take the pathological case: | | 1) A bean is requested to be deployed that has the security annotation, BUT the | bean class is not deployed yet so we don't this yet. | | 2) When the bean class is deployed it then knows it needs to add the aspect and | metadata, but the aspect class is not deployed yet. | It does know enough to add the metadata to construct the aspect once the class is | available. | It is the aspect that knows its dependencies. The aspect's factory doesn't know the security domain it depends on until it queries the bean's metadata. Furthermore, the aspect may need additional metadata from the bean class to determine its dependencies. An even quirkier example is an aspect that is created PER_JOINPOINT and that aspect has a dependency based on metadata contained in the joinpoint, not the class. I just don't see how you can define these types of dependencies in the current XML of the MC. Can you show me how? In fact, I don't think you can do it unless the MC has knowledge that an AOP framework is interacting with it. I don't think there is any other way than allowing the aspect factory to be able to register its dependencies itself. anonymous wrote : | 3) The aspect class is deployed we can look at it and see whether it has other | dependency injections. | Yes, but the aspect class may not be able to specify it's dependencies in static metadata. It may have to have knowledge of its bean class before it can know its dependencies. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861620#3861620 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861620 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=history ] Anil Saldhana reassigned JBAS-1283: --- Assign To: Anil Saldhana (was: Scott M Stark) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1275) JDK 1.3 OME running the testsuite
[ http://jira.jboss.com/jira/browse/JBAS-1275?page=history ] Clebert Suconic updated JBAS-1275: -- Attachment: CorrectAnalysis-jvm14.permanentCapacity.txt Due to a problem during the execution of the testcases I was getting wrong results. Here is a more accurate analysis for JVM1.4.2 Note: I marked where the PC (Permanent capacity) had the most significant changes I could notice. Here is a synchronization between the JUnit test which was running and the PC measure: Running org.jboss.test.jmsra.test.RaSyncRecUnitTestCase First hit to 37M Running org.jboss.test.jmx.test.JMXInvokerProxyUnitTestCase 39M (decreased to 35M after a while) Running org.jboss.test.lock.test.SpinUnitTestCase - 36M Running org.jboss.test.mdb.test.MDBUnitTestCase - 37M Running org.objectweb.jtests.jms.conform.topic.TemporaryTopicTest = 39M Running org.jboss.test.security.test.EJBSpecUnitTestCase = 40M Running org.jboss.test.security.test.LoginModulesUnitTestCase = 41M (Decreased to 38912 after a while) Running org.jboss.test.jbossmx.compliance.standard.InfoTortureTestCa = 40448 JDK 1.3 OME running the testsuite - Key: JBAS-1275 URL: http://jira.jboss.com/jira/browse/JBAS-1275 Project: JBoss Application Server Type: Bug Components: Test Suite Versions: JBossAS-3.2.7 Final Environment: [EMAIL PROTECTED] bin]$ $JAVA_HOME/bin/java -version java version 1.3.1_14 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_14-b03) Java HotSpot(TM) Client VM (build 1.3.1_14-b03, mixed mode) Reporter: Scott M Stark Assignee: Clebert Suconic Fix For: JBossAS-3.2.7 Final Attachments: CorrectAnalysis-jvm14.permanentCapacity.txt, jboss-all-config-tests_gc.log, jboss-testsuite-analysis.txt Time Spent: 1 day, 1 hour Remaining: 0 minutes When running the jboss-all-config-tests I have been seeing OutOfMemoryErrors well into the tests, but -verbose:gc clearly shows that there is plenty of memory. The process views also show that the handle/thread count is fine. That pretty much only left the MaxPermSize as becoming full, and I was able to run the tests using: JAVA_OPTS=-verbose:gc -XX:MaxPermSize=70m -Xmx128m This seems like an excessive amount of perm heap memory so I would like to look into this further. This does not happen when running JDK 1.4.2. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1275) JDK 1.3 OME running the testsuite
[ http://jira.jboss.com/jira/browse/JBAS-1275?page=comments#action_12314627 ] Clebert Suconic commented on JBAS-1275: --- For generating CorrectAnalysis-jvm14.permanentCapacity.txt I've used this line command: jstat -gcpermcapacity 3224 5s CorrectAnalysis-jvm14.permanentCapacity.txt Note that JBoss was running into JVM 1.4.2 with the Hotspot instrumentation active (-XX:+UsePerfData according to http://java.sun.com/performance/jvmstat/) I used jstat provided by JDK 5.0 against the process without any problems. JDK 1.3 OME running the testsuite - Key: JBAS-1275 URL: http://jira.jboss.com/jira/browse/JBAS-1275 Project: JBoss Application Server Type: Bug Components: Test Suite Versions: JBossAS-3.2.7 Final Environment: [EMAIL PROTECTED] bin]$ $JAVA_HOME/bin/java -version java version 1.3.1_14 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_14-b03) Java HotSpot(TM) Client VM (build 1.3.1_14-b03, mixed mode) Reporter: Scott M Stark Assignee: Clebert Suconic Fix For: JBossAS-3.2.7 Final Attachments: CorrectAnalysis-jvm14.permanentCapacity.txt, jboss-all-config-tests_gc.log, jboss-testsuite-analysis.txt Time Spent: 1 day, 1 hour Remaining: 0 minutes When running the jboss-all-config-tests I have been seeing OutOfMemoryErrors well into the tests, but -verbose:gc clearly shows that there is plenty of memory. The process views also show that the handle/thread count is fine. That pretty much only left the MaxPermSize as becoming full, and I was able to run the tests using: JAVA_OPTS=-verbose:gc -XX:MaxPermSize=70m -Xmx128m This seems like an excessive amount of perm heap memory so I would like to look into this further. This does not happen when running JDK 1.4.2. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JTA on JBoss] - Re: Why not always pad Xid?
I think whether or not to pad needs to happen at the JCA level. That the XAResource interface must be wrapped and when prepare or commit is called a new Xid should be created based on whether padding should be done or not. We will need the same for XAResource.recover as different XAResources require different flags here. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861641#3861641 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861641 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
I thought we were arguing over two things 1) That both joinpoint instances and invocation instances need metadata lookups. I think we both agree that joinpoint instances need metadata lookup. Do we agree that invocation intances need a separate metadata lookup? 2) I thought I had agreed that there doesn't need to be a separate API for getAnnotation and getMetaData. Maybe I agreed in my head, but forgot to post or maybe you didn't read one of my posts. 3) I thought we were disagreeing that the aspect factory needs a way to query for metadata from the bean class to determine additional dependencies. That I thought the aspect factory needed a way to query for metadata, and that you didn't. Some thoughts: * Class LEVEL: JBoss AOP Aspects are woven into a class at class static initialization time when using bytecode weaving (not a container + proxy). Will we be doing dependency management for this level of AOP? If so I'm worried about two things: complexity and performance. For complexity I'm worried that if we are doing dependency management at class static initialization we may run into difficult to debug deadlocks and circular class dependencies. For performance, I don't want to proxy aspect instances to solve complexity problems as the overall performance of JBoss AOP is quite sensitive as we're now down to the level of counting bytecode instructions. * Bean Level: Do aspect dependencies at this level only worry about beans managed by aspectized containers? * Finally, I think we need to discuss this on a separate thread, but I think the Joinpoints cannot use strings for parameters types, return types, and fields types. The AOP pointcut expression matcher will need to query these types to see if they have a corresponding annotation. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861638#3861638 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861638 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAOP-13) Refactor Tx interceptor
[ http://jira.jboss.com/jira/browse/JBAOP-13?page=history ] Bill Burke updated JBAOP-13: Environment: Version: 2.0 (was: 1.1) Fix Version: 2.0 (was: 1.1) Refactor Tx interceptor --- Key: JBAOP-13 URL: http://jira.jboss.com/jira/browse/JBAOP-13 Project: JBoss AOP Type: Feature Request Versions: 2.0 Reporter: Bill Burke Assignee: Bill Burke Fix For: 2.0 Refactor TxInterceptor so that it puts the TxType as the an interceptor so that there is no hash lookup and things are faster. Use PER_CLASS_JOINPOINT. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head build.690 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log2005043224Lbuild.690 BUILD COMPLETE-build.690Date of build:01/11/2005 14:32:24Time to build:29 minutes 24 secondsLast changed:01/11/2005 14:18:25Last log entry:JBREM-16: Fixed http invoker test to can be part of build tests as well as cleaned up a few other tests. Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(7)1.3modifiedtelrodremoting/tests/src/org/jboss/remoting/transport/http/HTTPInvokerClientTestCase.javaJBREM-16: Fixed http invoker test to can be part of build tests as well as cleaned up a few other tests.1.1addedtelrodremoting/tests/src/org/jboss/remoting/transport/http/HTTPInvokerTestCase.javaJBREM-16: Fixed http invoker test to can be part of build tests as well as cleaned up a few other tests.1.2modifiedtelrodremoting/tests/src/org/jboss/remoting/transport/http/HTTPInvokerTestClient.javaJBREM-16: Fixed http invoker test to can be part of build tests as well as cleaned up a few other tests.1.2modifiedtelrodremoting/tests/src/org/jboss/remoting/transport/http/HTTPInvokerTestServer.javaJBREM-16: Fixed http invoker test to can be part of build tests as well as cleaned up a few other tests.1.4modifiedtelrodremoting/tests/src/org/jboss/remoting/oneway/OnewayInvokerTestCase.javaJBREM-16: Fixed http invoker test to can be part of build tests as well as cleaned up a few other tests.1.3modifiedtelrodremoting/tests/src/org/jboss/remoting/detection/jndi/JNDIDetectorUnitTestCase.javaJBREM-16: Fixed http invoker test to can be part of build tests as well as cleaned up a few other tests.1.3modifiedbwang00tomcat/docs/tc5-clustering.xmlCorrected typo
[JBoss-dev] [JBoss JIRA] Created: (JBAOP-66) Backmerge AOP 1.1 to Branch_4_0
Backmerge AOP 1.1 to Branch_4_0 --- Key: JBAOP-66 URL: http://jira.jboss.com/jira/browse/JBAOP-66 Project: JBoss AOP Type: Bug Versions: 1.1 Reporter: Bill Burke Assigned to: Bill Burke Fix For: 1.1 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
On (3) I'm not sure what this aspect factory is.
I do agree that some metadata/config will only be known when we resolve the
annotations from the class. Whether this is done by the aspect factory I don't
know.
From the MC view point I was thinking of an integration point like:
| public ContainerFactory
| {
|BeanMetaData createContainer(BeanMetaData bmd)
| }
|
that gets invoked at describe time in the lifecycle.
This says take the requested BeanMetaData and replace it with a bean
wrapped in a container + all its resolved metadata.
To ease the life of the ContainerFactory I was also thinking that there
would be a ContainerMetaData abstraction.
This would be a specialization of the BeanMetaData targeted at the common
container configurations so...
1) The ContainerFactory doesn't has a simpler task
2) The ContainerFactory can spot the user has already preconfigured
some parts of container. In this case the container factory will just augment
the preconfigured container.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3861651#3861651
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861651
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (HIBERNATE-4) NPE in HibernateContext.prepareSession
[ http://jira.jboss.com/jira/browse/HIBERNATE-4?page=comments#action_12314630 ] sandro duarte commented on HIBERNATE-4: --- Having the same problem here: java.lang.NullPointerException at org.jboss.hibernate.session.HibernateContext.prepareSession(HibernateContext.java:171) at org.jboss.hibernate.session.HibernateContext.getSession(HibernateContext.java:99) at tre.rs.scai.service.ConsultaExtratoCommand.execute(Unknown Source) Jboss 4.0.0 WinXP NPE in HibernateContext.prepareSession -- Key: HIBERNATE-4 URL: http://jira.jboss.com/jira/browse/HIBERNATE-4 Project: Hibernate Type: Bug Reporter: SourceForge User Assignee: Gavin King Priority: Minor SourceForge Submitter: pilhuhn . Hi, this might be a pilot error ... When I try to obtain a session like this: Session = HibernateContext.getSession(java:/hibernate/SessionFactory); I get a NPE Caused by: java.lang.NullPointerException at org.jboss.hibernate.session.HibernateContext.prepareSession(HibernateContext.java:171) at org.jboss.hibernate.session.HibernateContext.getSession(HibernateContext.java:99) at de.bsd.adb_hibernate.server.ServerFacade.beispiel(ServerFacade.java:22) If I do it the classical way InitialContext ic = new InitialContext(); Object o = ic.lookup(java:/hibernate/SessionFactory); sf = (SessionFactory)o; Session sess = sf.openSession() it works as intended. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-25) ChannelClosedException does not always reconnect correctly
ChannelClosedException does not always reconnect correctly
--
Key: JGRP-25
URL: http://jira.jboss.com/jira/browse/JGRP-25
Project: JGroups
Type: Bug
Reporter: Bela Ban
Assigned to: Bela Ban
Fix For: 2.2.8
ChannelClosedException does not always reconnect correctly
Version JGroups 2.7
When a ChannelClosedException is encountered (legit
reasons), the sleep(1000) code below causes a race
condition which results in PullPushAdapter ignoring any
new messages.
The JChannel code calls the channelReconnected before
the sleep(1000) returns. This causes the
channelReconnected method to skip calling the start()
method. When the code after sleep() executes, the
receiver_thread is set to back to null thus causing
messages to be thrown out. Our workaround was to remove
the sleep code.
From PullPushAdapter.java:
public void channelReconnected(Address addr) {
if(receiver_thread == null)
start();
}
and
catch(ChannelClosedException closed_ex) {
// The sleep will cause problems if the channel
reconnects in under 1000 mills.
Util.sleep(1000);
receiver_thread=null;
break;
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
Ok, lets move the join point/string problem to a separate thread. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861653#3861653 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861653 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-24) ChannelClosedException does not always reconnect correctly
[ http://jira.jboss.com/jira/browse/JGRP-24?page=history ]
Bela Ban resolved JGRP-24:
--
Resolution: Done
Fix Version: 2.2.8
done
ChannelClosedException does not always reconnect correctly
--
Key: JGRP-24
URL: http://jira.jboss.com/jira/browse/JGRP-24
Project: JGroups
Type: Bug
Environment: Fedora Linux. JDK 1.4
Reporter: Tarek Hammoud
Assignee: Bela Ban
Fix For: 2.2.8
Version JGroups 2.2.7
When a ChannelClosedException is encountered (legit
reasons), the sleep(1000) code below causes a race
condition which results in PullPushAdapter ignoring any
new messages.
The JChannel code calls the channelReconnected before
the sleep(1000) returns. This causes the
channelReconnected method to skip calling the start()
method. When the code after sleep() executes, the
receiver_thread is set to back to null thus causing
messages to be thrown out. Our workaround was to remove
the sleep code.
From PullPushAdapter.java:
public void channelReconnected(Address addr) {
if(receiver_thread == null)
start();
}
and
catch(ChannelClosedException closed_ex) {
// The sleep will cause problems if the channel
reconnects in under 1000 mills.
Util.sleep(1000);
receiver_thread=null;
break;
Thank you.
Add a Comment
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCache] - Re: [CacheStoreInterceptor]failed committing transaction to
This has been fixed in the CVS (to be 1.2.1). It is an annoying error message, but doesn't change the correctness of the program View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861657#3861657 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861657 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
[EMAIL PROTECTED] wrote : I don't want static class initialization for the containers from the MC. | | This will work fine when beans are running inside somebody else's container | with the services from the wrapping container | but will fail for JBoss's internal beans where dependencies need to be | statisfied and ordered. | | The ordering needs to be done by the MC - negating any deadlocks. | | Pure JBossAOP | ClassNotFoundException x.Y | NestedException: NameNotFoundException: java:/jaas/SecurityDomain | | With the MC it will wait for the jndi binding or you will get an error about | incomplete dependencies | DeploymentException: Unsatisfied dependency for 'Name' | NestedException: SecurityDomain not deployed | For static class initialization, I'm not talking about containers. I'm talkinag about when you are just weaving aspects into a class whose instances are created outside of the MC. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861658#3861658 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861658 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-1) UDP/TCP doesn't work with 127.0.0.1 when there is no mcast route (works with 2.2.7)
[ http://jira.jboss.com/jira/browse/JGRP-1?page=history ] Bela Ban resolved JGRP-1: - Resolution: Done Problem was that DNS resolution slowed down the stack. Problem didn't occur with -Dresolve.dns=false UDP/TCP doesn't work with 127.0.0.1 when there is no mcast route (works with 2.2.7) --- Key: JGRP-1 URL: http://jira.jboss.com/jira/browse/JGRP-1 Project: JGroups Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.2.8 Original Estimate: 3 days Remaining: 3 days When all interfaces are turned off (unplumb on Solaris), and the only route is 127.0.0.1, then UDP and TCP won't find each other. This used to work in 2.2.7 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-8) Ability to stream files via remoting
[ http://jira.jboss.com/jira/browse/JBREM-8?page=comments#action_12314635 ] Tom Elrod commented on JBREM-8: Create a wrapper invocation to tell the server that have in stream invocation. Will also provide a callback locator uri. This means that the client itself will need to create (or register) with a connector and provide a handler. Later, when the server side handler calls to read, will need to stream the databack to the serve side. Ability to stream files via remoting Key: JBREM-8 URL: http://jira.jboss.com/jira/browse/JBREM-8 Project: JBoss Remoting Type: Feature Request Components: general Versions: 1.0.1 alpha Reporter: Tom Elrod Assignee: Tom Elrod Priority: Minor Fix For: 1.0.1 beta Would like to add ability for user to stream files using remoting. Initially requested by Dimitris for deploying files from management console using remoting. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-31) Exception handling in http server invoker
Exception handling in http server invoker - Key: JBREM-31 URL: http://jira.jboss.com/jira/browse/JBREM-31 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assigned to: Tom Elrod Need to catch any exception in the HTTPServerInvoker and send response to client via HTTP. There are several errors that can occur before getting to the invoke() method, so need to communicate these back to the calling client. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-32) HTTP Invoker - check for threading issues
HTTP Invoker - check for threading issues - Key: JBREM-32 URL: http://jira.jboss.com/jira/browse/JBREM-32 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assigned to: Tom Elrod Need to make HTTPServerInvoker thread safe. Currently calling several methods that may not be thread safe (just make sure are on the call stack instead of member vars of HTTPServerInvoker. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-33) Add GET support within HTTP server invoker
Add GET support within HTTP server invoker -- Key: JBREM-33 URL: http://jira.jboss.com/jira/browse/JBREM-33 Project: JBoss Remoting Type: Task Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assigned to: Tom Elrod Add support for GET request using HTTP invoker (only supports POST at this point) -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
Ok we agree on (1) and (2) as long as the last part of (1) means there will be a JoinPoint.getMetaData() and Invocation.getMetaData() The JoinPoint.getMetaData() allows the lookup to be done at deployment time but it does not require it. e.g. a perVM transaction demarcation aspect may choose to do this at runtime via invocation.getMetaData() - joinPoint.getMetaData(); View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861650#3861650 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861650 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-35) Servlet Invoker - counterpart to HTTP Invoker (runs within web container)
Servlet Invoker - counterpart to HTTP Invoker (runs within web container) - Key: JBREM-35 URL: http://jira.jboss.com/jira/browse/JBREM-35 Project: JBoss Remoting Type: Feature Request Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Minor Need a servlet invoker that will be the same as the HTTP Invoker (which is its own web server), but will run inside a web container (such as Tomcat) as a servlet. Will then process request same as HTTP Invoker after doPost()/doGet() called. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-15) merge UnifiedInvoker from remoting branch
[ http://jira.jboss.com/jira/browse/JBREM-15?page=history ] Tom Elrod updated JBREM-15: Environment: Fix Version: 1.0.1 final (was: 1.0.1 beta) Moving from 1.0.1 beta release to 1.0.1 final. merge UnifiedInvoker from remoting branch - Key: JBREM-15 URL: http://jira.jboss.com/jira/browse/JBREM-15 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.1 alpha Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.0.1 final Added UnifiedInvoker implementation (EJB 2.0 version) to remoting branch. Need to merge into CVS HEAD. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (EJBTHREE-39) Composite Key field in JoinColumn causes Repeated column in mapping
[ http://jira.jboss.com/jira/browse/EJBTHREE-39?page=history ] Bill Burke updated EJBTHREE-39: --- Version: Preview 3 Fix Version: Preview 3 Composite Key field in JoinColumn causes Repeated column in mapping --- Key: EJBTHREE-39 URL: http://jira.jboss.com/jira/browse/EJBTHREE-39 Project: EJB 3.0 Type: Bug Versions: Preview 3 Environment: jboss-4.0.1RC1, EBJ Preview II Reporter: Grayson Pierce Assignee: Bill Burke Fix For: Preview 3 Attachments: Composite.zip When a field is part of a composite key (via @Dependent) is also referenced in a JoinColumn for a OneToMany or ManyToOne relationship Hiberate produces the following error: I Depend On: Depends On Me: org.hibernate.MappingException: Repeated column in mapping for c lass org.jboss.tutorial.composite.bean.Customer should be mapped with insert=false update=false: flightId According to Hibernate discussions this problem can be fixed by marking the OneToMany as update=false, insert=false however this doesn't seem to be part of the 3.0 spec. For Example: http://forum.hibernate.org/viewtopic.php?t=927072highlight= many-to-one name=mtcepByCcidAndNcell update=false insert=false class=se.ericsson.lmc.ccl.model.dto.temp_lmcfrob_hbm.hibernate.Mtcep column name=ccid/ column name=ncell/ /many-to-one -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (EJBTHREE-38) EJB3 CVS is incompatible with hibernate3 CVS
[ http://jira.jboss.com/jira/browse/EJBTHREE-38?page=history ] Bill Burke updated EJBTHREE-38: --- Fix Version: Preview 3 EJB3 CVS is incompatible with hibernate3 CVS Key: EJBTHREE-38 URL: http://jira.jboss.com/jira/browse/EJBTHREE-38 Project: EJB 3.0 Type: Patch Versions: Preview 3 Reporter: Simeon Koptelov Assignee: Bill Burke Fix For: Preview 3 The methods of manipulation of listeners have changed in hibernate, so EJB3 CVS doesn't compile now. Here's the patch: Index: HibernateSessionFactory.java === RCS file: /cvsroot/jboss/jboss-ejb3/src/main/org/jboss/ejb3/HibernateSessionFactory.java,v retrieving revision 1.9 diff -u -r1.9 HibernateSessionFactory.java --- HibernateSessionFactory.java19 Dec 2004 22:35:16 - 1.9 +++ HibernateSessionFactory.java28 Dec 2004 23:38:42 - @@ -149,11 +149,11 @@ callbackHandler.add(entity); } - SessionEventListenerConfig listenerCfg = cfg.getSessionEventListenerConfig(); - listenerCfg.setPostDeleteEventListener(new EJB3PostDeleteEventListener(callbackHandler)); - listenerCfg.setPostLoadEventListener(new EJB3PostLoadEventListener(callbackHandler)); - listenerCfg.setPostUpdateEventListener(new EJB3PostUpdateEventListener(callbackHandler)); - listenerCfg.setPostInsertEventListener(new EJB3PostInsertEventListener(callbackHandler)); + cfg.setListener(post-delete, new EJB3PostDeleteEventListener(callbackHandler)); + cfg.setListener(post-load,new EJB3PostLoadEventListener(callbackHandler)); + cfg.setListener(post-update,new EJB3PostUpdateEventListener(callbackHandler)); + cfg.setListener(post-insert,new EJB3PostInsertEventListener(callbackHandler)); + /* AnnotationConfiguration cfg = new AnnotationConfiguration(); Iterator iter = classes.iterator(); -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (EJBTHREE-13) proxies must be castable to EJBObject/EJBLocalObject
[ http://jira.jboss.com/jira/browse/EJBTHREE-13?page=history ] Bill Burke updated EJBTHREE-13: --- Environment: Version: Preview 4 (was: Preview 3) Fix Version: Preview 4 (was: Preview 3) proxies must be castable to EJBObject/EJBLocalObject Key: EJBTHREE-13 URL: http://jira.jboss.com/jira/browse/EJBTHREE-13 Project: EJB 3.0 Type: Feature Request Versions: Preview 4 Reporter: Bill Burke Assignee: Bill Burke Fix For: Preview 4 Original Estimate: 1 day Remaining: 1 day This should be reviewed because there is talk of removing it from the specification. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-8) Ability to stream files via remoting
[ http://jira.jboss.com/jira/browse/JBREM-8?page=history ] Tom Elrod updated JBREM-8: --- Environment: Fix Version: 1.0.1 final (was: 1.0.1 beta) Moved from 1.0.1 beta to 1.0.1 final release. Ability to stream files via remoting Key: JBREM-8 URL: http://jira.jboss.com/jira/browse/JBREM-8 Project: JBoss Remoting Type: Feature Request Components: general Versions: 1.0.1 alpha Reporter: Tom Elrod Assignee: Tom Elrod Priority: Minor Fix For: 1.0.1 final Would like to add ability for user to stream files using remoting. Initially requested by Dimitris for deploying files from management console using remoting. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
I don't want static class initialization for the containers from the MC. This will work fine when beans are running inside somebody else's container with the services from the wrapping container but will fail for JBoss's internal beans where dependencies need to be statisfied and ordered. The ordering needs to be done by the MC - negating any deadlocks. Pure JBossAOP ClassNotFoundException x.Y NestedException: NameNotFoundException: java:/jaas/SecurityDomain With the MC it will wait for the jndi binding or you will get an error about incomplete dependencies DeploymentException: Unsatisfied dependency for 'Name' NestedException: SecurityDomain not deployed View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861652#3861652 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861652 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JGRP-25) ChannelClosedException does not always reconnect correctly
[ http://jira.jboss.com/jira/browse/JGRP-25?page=history ]
Bela Ban resolved JGRP-25:
--
Resolution: Done
Fixed according to suggestion
ChannelClosedException does not always reconnect correctly
--
Key: JGRP-25
URL: http://jira.jboss.com/jira/browse/JGRP-25
Project: JGroups
Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.2.8
Original Estimate: 1 day
Remaining: 1 day
ChannelClosedException does not always reconnect correctly
Version JGroups 2.7
When a ChannelClosedException is encountered (legit
reasons), the sleep(1000) code below causes a race
condition which results in PullPushAdapter ignoring any
new messages.
The JChannel code calls the channelReconnected before
the sleep(1000) returns. This causes the
channelReconnected method to skip calling the start()
method. When the code after sleep() executes, the
receiver_thread is set to back to null thus causing
messages to be thrown out. Our workaround was to remove
the sleep code.
From PullPushAdapter.java:
public void channelReconnected(Address addr) {
if(receiver_thread == null)
start();
}
and
catch(ChannelClosedException closed_ex) {
// The sleep will cause problems if the channel
reconnects in under 1000 mills.
Util.sleep(1000);
receiver_thread=null;
break;
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (HIBERNATE-4) NPE in HibernateContext.prepareSession
[ http://jira.jboss.com/jira/browse/HIBERNATE-4?page=history ] Ryan Campbell reassigned HIBERNATE-4: - Assign To: Steve Ebersole (was: Gavin King) NPE in HibernateContext.prepareSession -- Key: HIBERNATE-4 URL: http://jira.jboss.com/jira/browse/HIBERNATE-4 Project: Hibernate Type: Bug Reporter: SourceForge User Assignee: Steve Ebersole Priority: Minor SourceForge Submitter: pilhuhn . Hi, this might be a pilot error ... When I try to obtain a session like this: Session = HibernateContext.getSession(java:/hibernate/SessionFactory); I get a NPE Caused by: java.lang.NullPointerException at org.jboss.hibernate.session.HibernateContext.prepareSession(HibernateContext.java:171) at org.jboss.hibernate.session.HibernateContext.getSession(HibernateContext.java:99) at de.bsd.adb_hibernate.server.ServerFacade.beispiel(ServerFacade.java:22) If I do it the classical way InitialContext ic = new InitialContext(); Object o = ic.lookup(java:/hibernate/SessionFactory); sf = (SessionFactory)o; Session sess = sf.openSession() it works as intended. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
[EMAIL PROTECTED] wrote : On (3) I'm not sure what this aspect factory is.
Well, integrated with the MC the aspect factory would be responsible for
registering its dependencies to the MC. IT would also be responsible for
allocating instances of aspects based on their scope. (PER_VM, PER_CLASS,
etc...)
anonymous wrote :
| I do agree that some metadata/config will only be known when we resolve the
| annotations from the class. Whether this is done by the aspect factory I
don't know.
|
| From the MC view point I was thinking of an integration point like:
|
|
| | public ContainerFactory
| | {
| |BeanMetaData createContainer(BeanMetaData bmd)
| | }
| |
| that gets invoked at describe time in the lifecycle.
|
| This says take the requested BeanMetaData and replace it with a bean
| wrapped in a container + all its resolved metadata.
|
Will BeanMetaData have an API to register dependencies? SO that the container
or container factory can decide what dependencies it requires and so you can
support all that stuff I talked about before where the aspect knows its
dependencies, not the bean?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3861655#3861655
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861655
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design the new POJO MicroContainer] - Re: Resolving MetaData/Annotations
Yes, BeanMetaData has a number of mechanisms for creating dependencies. Off topic: It is still on my todo list to come up with a generic mechanism for this so the KernelController will spot any dependency in the metadata and generate the necessary dependency list. Currently it is a bit hardwired, e.g. it needs to know that depends ... adds a dependency to the KernelControllerState.CONFIGURED stage of the deployment. See BasicKernelController.preprocessMetaData() View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861679#3861679 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861679 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-30) Better integration for registering invokers with MBeanServer
Better integration for registering invokers with MBeanServer Key: JBREM-30 URL: http://jira.jboss.com/jira/browse/JBREM-30 Project: JBoss Remoting Type: Task Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Minor All the invokers (socket, rmi, http) need to be registered with an MBeanServer so can be configured and managed via JMX. Configuration has been added to the invokers via service.xml, but is not direct, meaning that it is the Connector that is really the service mbean, so the invokers have to be registered separately. This is fine if running within JBoss and can lookup the JBoss MBeanServer (same one used by the microkernel via the MBeanServerLocator.locateJBoss() call). The problem arises when running stand alone and not within JBoss AS. Need to figure out a way to handle this case. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-34) Need to add configuration properties for HTTP server invoker
Need to add configuration properties for HTTP server invoker Key: JBREM-34 URL: http://jira.jboss.com/jira/browse/JBREM-34 Project: JBoss Remoting Type: Task Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Minor Need to add configuration via JMX and service xml for HTTP invoker. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBREM-16) Finish HTTP Invoker
[ http://jira.jboss.com/jira/browse/JBREM-16?page=history ] Tom Elrod closed JBREM-16: --- Resolution: Done HTTP Invoker client and server (stand-alone, so no web container needed) implemented. Some remaining issues that have been opened as new Jira issues. Finish HTTP Invoker --- Key: JBREM-16 URL: http://jira.jboss.com/jira/browse/JBREM-16 Project: JBoss Remoting Type: Task Components: transport Versions: 1.0.1 alpha Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.0.1 beta Need to complete the HTTPClientInvoker. Also, would like to have two server invokers based on HTTP; one which is servlet based (i.e. ServletServerInvoker) and would run within a web container if one exists and one which is standalone (i.e. HTTPServerInvoker) and based off the SocketServerInvoker that uses a different marshaller for decoding the HTTP request. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-27) Support for HTTP/HTTPS proxy
[ http://jira.jboss.com/jira/browse/JBREM-27?page=history ] Tom Elrod updated JBREM-27: Environment: Fix Version: 1.0.1 final (was: 1.0.1 beta) Moved from 1.0.1 beta to 1.0.1 final release. Support for HTTP/HTTPS proxy Key: JBREM-27 URL: http://jira.jboss.com/jira/browse/JBREM-27 Project: JBoss Remoting Type: Feature Request Components: transport Reporter: Thomas Diesler Assignee: Tom Elrod Fix For: 1.0.1 final This request showed up on the web services forum. Proxies are currently suported in axis-ws4ee.jar -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBPTL-60) CMS Portlet User Guide
[ http://jira.jboss.com/jira/browse/JBPTL-60?page=history ] Roy Russo resolved JBPTL-60: Resolution: Done Fix Version: 2.0 Alpha CMS Portlet User Guide -- Key: JBPTL-60 URL: http://jira.jboss.com/jira/browse/JBPTL-60 Project: JBoss Portal Type: Sub-task Reporter: Roy Russo Assignee: Roy Russo Fix For: 2.0 Alpha -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBPTL-60) CMS Portlet User Guide
[ http://jira.jboss.com/jira/browse/JBPTL-60?page=history ] Roy Russo closed JBPTL-60: -- CMS Portlet User Guide -- Key: JBPTL-60 URL: http://jira.jboss.com/jira/browse/JBPTL-60 Project: JBoss Portal Type: Sub-task Reporter: Roy Russo Assignee: Roy Russo Fix For: 2.0 Alpha -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=comments#action_12314640 ] Anil Saldhana commented on JBAS-1283: - If I make the java2ClassLoadingCompliance to true, the webapp deploys properly and I can access the index.jsp with no errors. = ?xml version='1.0' encoding='UTF-8' ? !DOCTYPE jboss-web PUBLIC -//JBoss//DTD Web Application 2.3//EN http://www.jboss.org/j2ee/dtd/jboss-web_3_0.dtd; jboss-web class-loading java2ClassLoadingCompliance=true loader-repositorydot.com:loader=app1 loader-repository-configjava2ParentDelegation=true/loader-repository-config /loader-repository /class-loading /jboss-web I notice that your lib directory has dom4j-full.jar (which contains jaxen) and a seperate jaxen-full.jar. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at
[JBoss-dev] [Design of JBoss Portal] - Migrating to JBoss from Weblogic
Hi, We are in the process of migrating from weblogic to Jboss. Currently we have these properties set up in weblogic-ejb-jar.xml for container managed transactions ,what are the xml elements I can use to get same functionality what I get from weblogic. These are the properties currently in weblogic. max-beans-in-cache100/max-beans-in-cache idle-timeout-seconds600/idle-timeout-seconds read-timeout-seconds60/read-timeout-seconds delay-updates-until-end-of-txtrue/delay-updates-until-end-of-tx finders-load-beanfalse/finders-load-bean transaction-isolation isolation-levelTRANSACTION_READ_COMMITTED/isolation-level /transaction-isolation Thanks XJava View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861699#3861699 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861699 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=comments#action_12314641 ] Jeremy Brown commented on JBAS-1283: What's the net effect of setting java2ClassLoadingCompliance to true or false? Is there a wiki topic or doco about this? Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at
[JBoss-dev] jboss-3.2-testsuite build.46 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log2005090441Lbuild.46 BUILD COMPLETE-build.46Date of build:01/11/2005 19:04:41Time to build:88 minutes 16 seconds Unit Tests: (1909) Total Errors and Failures: (26)unknownorg.jboss.test.jbossmq.test.LargeMessageUnitTestCaseunknownorg.jboss.test.jbossmq.test.OILConnectionUnitTestCasetestQueueMessageOrderorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestRequestReplyQueueorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestTemporaryQueueDeleteorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestTemporaryTopicDeleteorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestInvalidDestinationQueueSendorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestInvalidDestinationQueueBrowseorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestInvalidDestinationTopicPublishorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestErrorsTopicSubscribeorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestCreateQueueorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestMessageListenerorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestApplicationServerStufforg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestTopicsorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestTopicNoLocalorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestTopicNoLocalBounceorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestTopicSelectorChangeorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestTopicSelectorNullOrEmptyorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestSendReceiveOutdatedorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestSendReceiveExpiredorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestSendListenOutdatedorg.jboss.test.jbossmq.test.OILJBossMQUnitTestCasetestProgramaticProxyorg.jboss.test.jmx.test.JMXInvokerProxyUnitTestCasetestServerFoundorg.jboss.test.jmx.test.JMXInvokerProxyUnitTestCaseunknownorg.jboss.test.security.test.SRPLoginModuleUnitTestCaseunknownorg.jboss.test.security.test.SRPUnitTestCasetestServletSessionFailoverorg.jboss.test.cluster.test.WebSessionTestCase Modifications since last build:(0)
[JBoss-dev] [JBoss JIRA] Created: (JBCACHE-36) Run testsuite on multi-CPU boxes in ATL lab
Run testsuite on multi-CPU boxes in ATL lab --- Key: JBCACHE-36 URL: http://jira.jboss.com/jira/browse/JBCACHE-36 Project: JBoss Cache Type: Task Versions: 1.2 Reporter: Bela Ban Assigned to: Bela Ban Fix For: 1.2.1 to detect concurrency issues -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head build.691 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050111210713Lbuild.691 BUILD COMPLETE-build.691Date of build:01/11/2005 21:07:13Time to build:25 minutes 49 secondsLast changed:01/11/2005 20:35:54Last log entry:Updated Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(34)1.3modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/getAttribute.jspUpdated1.3modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/invalidateSession.jspUpdated1.5modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/setSession.jspUpdated1.4modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/setPerfSession.jspChanged from New to new1.4modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/setSession.jspChanged from New to new1.3modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchWriter.javaperformance tune1.3modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/test/TestForceTime.javaperformance tune1.2deletedpatriot1burketransaction/src/main/org/jboss/tm/recovery/Batch.javaperformance tune1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchReceipt.javaperformance tune1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLogger.javaperformance tune1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchWriter.javaperformance tune1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/test/TestForceTime.javaperformance tune1.29modifiedosdchicagoserver/src/main/org/jboss/web/WebServer.javaWhen a service fails to bind to a port because of java.net.BindException, append the port number to the error message so that basic users can figure out which port is already in use.1.12modifiedosdchicagoserver/src/main/org/jboss/invocation/pooled/server/PooledInvoker.javaWhen a service fails to bind to a port because of java.net.BindException, append the port number to the error message so that basic users can figure out which port is already in use.1.4modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/test/RecoverabilityTestCase.javafinish recovery prototype1.3modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/interfaces/DummyXAResource.javafinish recovery prototype1.3modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/interfaces/MockLogger.javafinish recovery prototype1.2modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/bean/MockLoggerService.javafinish recovery prototype1.2modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/bean/MockLoggerServiceMBean.javafinish recovery prototype1.38modifiedpatriot1burketransaction/src/main/org/jboss/tm/TransactionImpl.javafinish recovery prototype1.7modifiedpatriot1burketransaction/src/main/org/jboss/tm/XidImpl.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/Batch.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchLog.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLogReader.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLogger.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLoggerService.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLoggerServiceMBean.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchWriter.javafinish recovery prototype1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/FileRecoveryLogReader.javafinish recovery prototype1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/RecoveryLogReader.javafinish recovery prototype1.3modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/RecoveryManager.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/test/TestForceTime.javafinish recovery prototype1.122modifiedpatriot1burkeserver/src/etc/conf/default/jboss-service.xmlfinish recovery prototype1.8modifiedbwang00testsuite/src/main/org/jboss/test/cluster/test/BaseTest.javaUpdated
[JBoss-dev] [Design of JBoss Portal] - Re: Adding personal portlet in jboss portal
I have commited that in the CVS. You can have a look at the forums portlet which makes use of the forum-pages.xml which is in WEB-INF. here it is : | pages |portal-namedefault/portal-name |page | page-nameforums/page-name | window | window-nameForumsPortletWindow/window-name | instance-ref/portal-forums.ForumsPortlet.ForumsPortletInstance/instance-ref | defaulttrue/default | regionuser1/region | height0/height | /window |/page | /pages | this creates in the default portal a page named forums containing one window. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861706#3861706 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861706 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Portal] - Re: package renaming after alpha
+1 View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861709#3861709 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861709 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JTA on JBoss] - Re: Tx Recovery Prototype
Ok, just did another version tonight. The new impl is a batch queue using nio ByteBuffers. I did some quick benching and its pretty quick. Got a max of about 17,000 txs/second with 1030 threads running in parallel. THis is with a dual-cpu xeon 2.4 Ghz with 10,000 rpm scsi. Also updated the WIKI page on recovery with new thoughts. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861704#3861704 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861704 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JTA on JBoss] - Re: Tx Recovery Prototype
forgot to say the above bench is with RH 8.0 View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861705#3861705 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861705 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Portal] - package renaming after alpha
we are going to rename packages after alpha release, I propose the following : | org.jboss.nukes.portal - org.jboss.portal.server | org.jboss.nukes.portlet - org.jboss.portal.portlet | org.jboss.nukes.core- org.jboss.portal (not sure) | | jboss portlet API - org.jboss.portlet | XXX portlet- org.jboss.portlet.XXX | View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861708#3861708 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861708 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-4.0-jdk-matrix build.60 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-jdk-matrix?log=log20050111222558Lbuild.60 BUILD COMPLETE-build.60Date of build:01/11/2005 22:25:58Time to build:23 minutes 9 seconds Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(0)
[JBoss-dev] [JBoss JIRA] Created: (JBREM-36) performance tests fail for http transports
performance tests fail for http transports -- Key: JBREM-36 URL: http://jira.jboss.com/jira/browse/JBREM-36 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.0.1 final Either some of the messages are getting lost or the invoker is so slow that the test finishes before invoker can finish sending messages. Says that it only got about 4900 messages of 5000 it should have. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head-jdk-matrix build.55 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20050111225416Lbuild.55 BUILD COMPLETE-build.55Date of build:01/11/2005 22:54:16Time to build:28 minutes 7 secondsLast changed:01/11/2005 22:17:23Last log entry:Fix package Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(57)1.2modifiednihilitywebservice/test/java/org/jboss/test/ws/tools/WSDL20ToJavaTestCase.javaFix package1.7modifiedpatriot1burkeserver/src/etc/conf/default/xmdesc/TransactionManagerService-xmbean.xmladd correct attributeadd attribute to tx xmdesc1.123modifiedpatriot1burkeserver/src/etc/conf/default/jboss-service.xmladd correct attributeadd attribute to tx xmdesc1.3modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/getAttribute.jspUpdated1.3modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/invalidateSession.jspUpdated1.5modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/setSession.jspUpdated1.4modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/setPerfSession.jspChanged from New to new1.4modifiedbwang00testsuite/src/resources/cluster/http/http-scoped/setSession.jspChanged from New to new1.3modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchWriter.javaperformance tune1.3modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/test/TestForceTime.javaperformance tune1.2deletedpatriot1burketransaction/src/main/org/jboss/tm/recovery/Batch.javaperformance tune1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchReceipt.javaperformance tune1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLogger.javaperformance tune1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchWriter.javaperformance tune1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/test/TestForceTime.javaperformance tune1.29modifiedosdchicagoserver/src/main/org/jboss/web/WebServer.javaWhen a service fails to bind to a port because of java.net.BindException, append the port number to the error message so that basic users can figure out which port is already in use.1.12modifiedosdchicagoserver/src/main/org/jboss/invocation/pooled/server/PooledInvoker.javaWhen a service fails to bind to a port because of java.net.BindException, append the port number to the error message so that basic users can figure out which port is already in use.1.4modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/test/RecoverabilityTestCase.javafinish recovery prototype1.3modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/interfaces/DummyXAResource.javafinish recovery prototype1.3modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/interfaces/MockLogger.javafinish recovery prototype1.2modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/bean/MockLoggerService.javafinish recovery prototype1.2modifiedpatriot1burketestsuite/src/main/org/jboss/test/recover/bean/MockLoggerServiceMBean.javafinish recovery prototype1.38modifiedpatriot1burketransaction/src/main/org/jboss/tm/TransactionImpl.javafinish recovery prototype1.7modifiedpatriot1burketransaction/src/main/org/jboss/tm/XidImpl.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/Batch.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchLog.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLogReader.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLogger.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLoggerService.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchRecoveryLoggerServiceMBean.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/BatchWriter.javafinish recovery prototype1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/FileRecoveryLogReader.javafinish recovery prototype1.2modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/RecoveryLogReader.javafinish recovery prototype1.3modifiedpatriot1burketransaction/src/main/org/jboss/tm/recovery/RecoveryManager.javafinish recovery prototype1.1addedpatriot1burketransaction/src/main/org/jboss/tm/recovery/test/TestForceTime.javafinish recovery prototype1.122modifiedpatriot1burkeserver/src/etc/conf/default/jboss-service.xmlfinish recovery prototype1.8modifiedbwang00testsuite/src/main/org/jboss/test/cluster/test/BaseTest.javaUpdated1.3modifiedtelrodremoting/tests/src/org/jboss/remoting/transport/http/HTTPInvokerClientTestCase.javaJBREM-16: Fixed http invoker test to can be part of build tests as well as cleaned up a few other
[JBoss-dev] jboss-head build.692 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050111234452Lbuild.692 BUILD COMPLETE-build.692Date of build:01/11/2005 23:44:52Time to build:21 minutes 50 secondsLast changed:01/11/2005 22:17:23Last log entry:Fix package Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(3)1.2modifiednihilitywebservice/test/java/org/jboss/test/ws/tools/WSDL20ToJavaTestCase.javaFix package1.7modifiedpatriot1burkeserver/src/etc/conf/default/xmdesc/TransactionManagerService-xmbean.xmladd correct attributeadd attribute to tx xmdesc1.123modifiedpatriot1burkeserver/src/etc/conf/default/jboss-service.xmladd correct attributeadd attribute to tx xmdesc
[JBoss-dev] [JBoss JIRA] Created: (JBREM-37) backport to 4.0 branch before 1.0.1 final release
backport to 4.0 branch before 1.0.1 final release - Key: JBREM-37 URL: http://jira.jboss.com/jira/browse/JBREM-37 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.1 beta Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.0.1 final Need to make sure get everything from final release backported to the 4.0 branch. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-60) JBossCache based http session replication does not handle load balanced requests
[ http://jira.jboss.com/jira/browse/JBAS-60?page=history ] Ben Wang resolved JBAS-60: -- Resolution: Done This has been fixed both in 4.0 and head. The WebSessionTestCase has also been re-activated. To fix this, a cache invalidation approach has been used. Now, session node stores a version number (with key VERION_KEY) in addition to its session data. JBossCacheService now subscribes to TreeCache event listener. Whenever a node modification occurrs, if it is of fqn that stores the fqn (that is, if VERSION_KEY is available), it will check this version against that of in-memory. If this version is newer, it will mark the session isOutdated flag to true. Next time a session is retrieved (e.g., findSession), it will always check it the im-memory data is outdated. If it is, it will retrieve it from the data store and updated the im-memory data. I will update the doc as well. Note this fix is not back-ported to 3.2 release. JBossCache based http session replication does not handle load balanced requests Key: JBAS-60 URL: http://jira.jboss.com/jira/browse/JBAS-60 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.0 Final, JBossAS-4.0.1 Final Reporter: Scott M Stark Assignee: Ben Wang Fix For: JBossAS-4.0.2RC1 Original Estimate: 1 week Remaining: 1 week The current http session replication on top of JBossCache does not handle a load balanced request scenario due to the fact that the associated session manager does not listen for node change events to know when to update the local session store. Either the session manager needs to be rewritten to not use a second level store of attributes, or the it needs to listen for the update events. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-4.0-testsuite build.38 Build Successful
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=log20050112004806Lbuild.38 BUILD COMPLETE-build.38Date of build:01/12/2005 00:48:06Time to build:113 minutes 37 seconds Unit Tests: (2305) Total Errors and Failures: (6)testAspectorg.jboss.test.aop.test.RemotingUnitTestCaseunknownorg.jboss.test.jbossmq.test.LargeMessageUnitTestCaseunknownorg.jboss.test.jbossmq.test.OILConnectionUnitTestCasetestPoolingorg.jboss.test.cts.test.MDBUnitTestCasetestPoolingorg.jboss.test.securitymgr.test.MDBUnitTestCasetestJBossEditorsorg.jboss.test.util.test.PropertyEditorsUnitTestCase Modifications since last build:(0)
