RE: [JBoss-dev] FW: [jboss-cvs] build/jboss ...
Ok, thanks. Comment added. On Fri, 2006-03-17 at 03:59 -0600, Dimitris Andreadis wrote: http://jira.jboss.com/jira/browse/JBAS-2955 If Franscisco wants to add any comments on the upgrade. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: 16 March, 2006 21:12 To: jboss-development@lists.sourceforge.net; Francisco Reverbel Subject: RE: [JBoss-dev] FW: [jboss-cvs] build/jboss ... Yes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Campbell Sent: Thursday, March 16, 2006 10:45 AM To: Francisco Reverbel Cc: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] FW: [jboss-cvs] build/jboss ... We need a JIRA task in the JBAS project for any 3rd party library upgrades so that they show up in the changelog, right? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francisco Reverbel Sent: Thursday, March 16, 2006 12:02 AM To: [EMAIL PROTECTED] Subject: [jboss-cvs] build/jboss ... User: reverbel Date: 06/03/16 01:01:30 Modified:jbossTag: Branch_4_0 build-thirdparty.xml Log: JacORB upgrade to release 2.2.3. Revision ChangesPath No revision No revision 1.1.2.83 +1 -1 build/jboss/build-thirdparty.xml (In the diff below, changes in quantity of whitespace are not shown.) Index: build-thirdparty.xml === RCS file: /cvsroot/jboss/build/jboss/build-thirdparty.xml,v retrieving revision 1.1.2.82 retrieving revision 1.1.2.83 diff -u -b -r1.1.2.82 -r1.1.2.83 --- build-thirdparty.xml6 Mar 2006 06:23:25 - 1.1.2.82 +++ build-thirdparty.xml16 Mar 2006 06:01:30 - 1.1.2.83 @@ -87,7 +87,7 @@ componentref name=hibernate-entitymanager version=3.1beta6/ componentref name=hsqldb version=1.8.0.2/ componentref name=ibm-wsdl4j version=1.5.2/ - componentref name=jacorb version=2.2.1jboss/ + componentref name=jacorb version=2.2.3/ componentref name=javassist version=3.1RC2/ componentref name=jaxen version=1.1beta4/ componentref name=jboss/aop version=1.3.4/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720; dat=121642 ___ jboss-cvs-commits mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-cvs-commits --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Moving org.jboss.naming.* from server into naming module
+1 I ran into the very same issue while working on the DTM. See http://jira.jboss.com/jira/browse/JBAS-2190 Regards, Francisco On Mon, 2006-02-27 at 15:26 -0600, Scott M Stark wrote: We have a number of org.jnp.interfaces.NamingContextFactory subclasses that are in the server module which should really be in the naming module to avoid unnecessary dependencies on the server module, and jboss.jar: org.jboss.naming.BridgeNamingContextFactory org.jboss.naming.NamingContextFactory org.jboss.iiop.naming.ORBInitialContextFactory The issue came up when looking at these security related variations which should subclass the org.jboss.naming.NamingContextFactory version to pickup its ability to remember non-default InitialContextFactory environment settings: org.jboss.security.jndi.LoginInitialContextFactory org.jboss.security.jndi.JndiLoginInitialContextFactory I'm tempted to move all of the server org.jboss.naming.* classes into the naming module to avoid spliting this package across jars, but there jboss-system dependencies, and jmx dependencies that require further refactoring. It should probably be done anyway in preparation for the mc migration. I'll wait a day for feedback before starting this move. If I do move this over to naming I want to move the cvs history along with it. Scott Stark VP Architecture Technology JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Could not run jacorb on 64 bit jdk
Yes, I see that the VerifyError is thrown when you run the IDL compiler. It looks like a JVM bug. Even though I know JacORB's implementation of the ORB run-time library fairly well, I have never looked at the IDL compiler. Do you know if a VerifyError also happens at run time, with JacORB's ORB on a 64-bit JVM? Or the problem happens only during IDL compilation? On Mon, 2006-02-13 at 17:11 -0600, Ryan Campbell wrote: Francisco, Just to make it clear, we are trying to build JBoss on 64bit JVM’s and we get this fatal exception when trying to run the jacorb parser: Exception in thread main java.lang.VerifyError: (class: org/jacorb/idl/parser, method: clinit signature: ()V) Call to wrong initialization method Can you patch this? We aren’t getting a response from the jacorb list. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajesh Rajasekaran Sent: Monday, February 13, 2006 5:04 PM To: jboss-development@lists.sourceforge.net Cc: Francisco Reverbel Subject: [JBoss-dev] FW: Could not run jacorb on 64 bit jdk __ From: Rajesh Rajasekaran Sent: Friday, February 10, 2006 12:05 PM To: '[EMAIL PROTECTED]' Subject: Could not run jacorb on 64 bit jdk This is related to the bug #468 http://www.jacorb.org/cgi-bin/bugzilla/long_list.cgi?buglist=468 We are trying to support Jboss on 64 bit jdk’s and this bug is a major blocker. A fix for this ASAP would help us proceed with our process. Thanks Rajesh JBoss QA --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1646) Define OTS-like interfaces for the DTM
[ http://jira.jboss.com/jira/browse/JBAS-1646?page=history ] Francisco Reverbel closed JBAS-1646: Define OTS-like interfaces for the DTM -- Key: JBAS-1646 URL: http://jira.jboss.com/jira/browse/JBAS-1646 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel Define OTS-like interfaces for the following DTM objects associated with a given transaction: Terminator, Coordinator, Resource, Synchronization, and RecoveryCoordinator. These interfaces allow those objects to be manipulated in a unified way, regardless of whether they are accessible via JBoss remoting or via CORBA/IIOP. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1655) Add to TransactionImpl a method that enlists a DTM Resource...
[ http://jira.jboss.com/jira/browse/JBAS-1655?page=history ] Francisco Reverbel closed JBAS-1655: Resolution: Done Add to TransactionImpl a method that enlists a DTM Resource... -- Key: JBAS-1655 URL: http://jira.jboss.com/jira/browse/JBAS-1655 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel Ensure that TransactionImpl has methods that do the actual work for all OTS/DTM objects and for XATerminator. Most of the needed methods already are in place, but some need to be added (e.g., a method to enlist a DTM Resource). -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1654) Extend TransactionImpl
[ http://jira.jboss.com/jira/browse/JBAS-1654?page=history ] Francisco Reverbel closed JBAS-1654: Resolution: Done Extend TransactionImpl -- Key: JBAS-1654 URL: http://jira.jboss.com/jira/browse/JBAS-1654 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel Extend TransactionImpl so that it knows about the following DTM objects: Coordinator, Resource, and RecoveryCoordinator. Besides having a list of XA resources, a TransactionImpl instance will have a list of DTM Resources, each of which represents either a JBoss remoting-based resource or a (properly wrapped) OTS resource. It may also have a parent coordinator, which will be a DTM Coordinator (either a remoting-based coordinator or an OTS coordinator). If if has a parent coordinator, it must register itself as a Resource with that coordinator. The TransactionImpl must drive the 2PC across all XA resources and DTM resources. Logging and recovery are not included in this step. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1653) Review TransactionImpl
[ http://jira.jboss.com/jira/browse/JBAS-1653?page=history ] Francisco Reverbel closed JBAS-1653: Resolution: Done Review TransactionImpl -- Key: JBAS-1653 URL: http://jira.jboss.com/jira/browse/JBAS-1653 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel Review TransactionImpl with respect to LocalId/GlobalId association and transaction importing. An imported transaction should have a LocalId just like a non-imported one. (The local id is embedded into the CORBA references or into the JBoss remoting-based proxies for the transaction Coordinator, Terminator, etc.) -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1649) Write OTS wrappers
[ http://jira.jboss.com/jira/browse/JBAS-1649?page=history ] Francisco Reverbel closed JBAS-1649: Write OTS wrappers -- Key: JBAS-1649 URL: http://jira.jboss.com/jira/browse/JBAS-1649 Project: JBoss Application Server Type: Sub-task Reporter: Francisco Reverbel Assignee: Francisco Reverbel Write some trivial OTS wrappers that implement the DTM interfaces by delegating the work to OTS objects. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1648) Complete the existing implementation of the OTS interfaces
[ http://jira.jboss.com/jira/browse/JBAS-1648?page=history ] Francisco Reverbel closed JBAS-1648: Complete the existing implementation of the OTS interfaces -- Key: JBAS-1648 URL: http://jira.jboss.com/jira/browse/JBAS-1648 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel The existing OTS servant does not yet implements register_resource, recreate, and replay_completion. The implementation of those methods will delegate the actual work to the TransactionImpl instance the represents the transaction. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1647) Provide JBoss remoting-based implementations of the DTM interfaces
[ http://jira.jboss.com/jira/browse/JBAS-1647?page=history ] Francisco Reverbel closed JBAS-1647: Provide JBoss remoting-based implementations of the DTM interfaces -- Key: JBAS-1647 URL: http://jira.jboss.com/jira/browse/JBAS-1647 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel The implementations will delegate the actual work to TransactionImpl instances. Besides the similarity in their interfaces, remoting-based DTM objects (Resource, Coordinator, etc.) must be similar to OTS objects also in that their references (proxies) are convertible to strings and vice-versa. This will be needed for logging. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1646) Define OTS-like interfaces for the DTM
Define OTS-like interfaces for the DTM -- Key: JBAS-1646 URL: http://jira.jboss.com/jira/browse/JBAS-1646 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Define OTS-like interfaces for the following DTM objects associated with a given transaction: Terminator, Coordinator, Resource, Synchronization, and RecoveryCoordinator. These interfaces allow those objects to be manipulated in a unified way, regardless of whether they are accessible via JBoss remoting or via CORBA/IIOP. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1647) Provide JBoss remoting-based implementations of the DTM interfaces
Provide JBoss remoting-based implementations of the DTM interfaces -- Key: JBAS-1647 URL: http://jira.jboss.com/jira/browse/JBAS-1647 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel The implementations will delegate the actual work to TransactionImpl instances. Besides the similarity in their interfaces, remoting-based DTM objects (Resource, Coordinator, etc.) must be similar to OTS objects also in that their references (proxies) are convertible to strings and vice-versa. This will be needed for logging. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1647) Provide JBoss remoting-based implementations of the DTM interfaces
[ http://jira.jboss.com/jira/browse/JBAS-1647?page=history ] Francisco Reverbel updated JBAS-1647: - Assign To: Francisco Reverbel Security Level: (was: Public) Provide JBoss remoting-based implementations of the DTM interfaces -- Key: JBAS-1647 URL: http://jira.jboss.com/jira/browse/JBAS-1647 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel The implementations will delegate the actual work to TransactionImpl instances. Besides the similarity in their interfaces, remoting-based DTM objects (Resource, Coordinator, etc.) must be similar to OTS objects also in that their references (proxies) are convertible to strings and vice-versa. This will be needed for logging. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1649) Write OTS wrappers
Write OTS wrappers -- Key: JBAS-1649 URL: http://jira.jboss.com/jira/browse/JBAS-1649 Project: JBoss Application Server Type: Sub-task Reporter: Francisco Reverbel Assigned to: Francisco Reverbel -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1649) Write OTS wrappers
[ http://jira.jboss.com/jira/browse/JBAS-1649?page=history ] Francisco Reverbel updated JBAS-1649: - Description: Write some trivial OTS wrappers that implement the DTM interfaces by delegating the work to OTS objects. Environment: Security Level: (was: Public) Write OTS wrappers -- Key: JBAS-1649 URL: http://jira.jboss.com/jira/browse/JBAS-1649 Project: JBoss Application Server Type: Sub-task Reporter: Francisco Reverbel Assignee: Francisco Reverbel Write some trivial OTS wrappers that implement the DTM interfaces by delegating the work to OTS objects. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1650) Propagate full tx context along with JBoss remoting invocations
Propagate full tx context along with JBoss remoting invocations --- Key: JBAS-1650 URL: http://jira.jboss.com/jira/browse/JBAS-1650 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Enlarge the transaction context propagated along with JBoss remoting invocations. The current context has only a GlobalId/Xid, it must include also a Coordinator reference. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1651) Make the TPC factory/importer/exporter configurable
Make the TPC factory/importer/exporter configurable --- Key: JBAS-1651 URL: http://jira.jboss.com/jira/browse/JBAS-1651 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Make the TPC factory/importer/exporter configurable so that the full context (GlobalId + Coordinator reference) is propagated only if the DTM is actually used (no additional overhead for DTMless server configs). -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1652) Propagate OTS context in IIOP invocations from the JBoss server
Propagate OTS context in IIOP invocations from the JBoss server --- Key: JBAS-1652 URL: http://jira.jboss.com/jira/browse/JBAS-1652 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Propagate the OTS context along with invocations issued by the JBoss server. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1651) Make the TPC factory/importer/exporter configurable
[ http://jira.jboss.com/jira/browse/JBAS-1651?page=history ] Francisco Reverbel updated JBAS-1651: - Assign To: Francisco Reverbel Security Level: (was: Public) Make the TPC factory/importer/exporter configurable --- Key: JBAS-1651 URL: http://jira.jboss.com/jira/browse/JBAS-1651 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel Make the TPC factory/importer/exporter configurable so that the full context (GlobalId + Coordinator reference) is propagated only if the DTM is actually used (no additional overhead for DTMless server configs). -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1653) Review TransactionImpl
Review TransactionImpl -- Key: JBAS-1653 URL: http://jira.jboss.com/jira/browse/JBAS-1653 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Review TransactionImpl with respect to LocalId/GlobalId association and transaction importing. An imported transaction should have a LocalId just like a non-imported one. (The local id is embedded into the CORBA references or into the JBoss remoting-based proxies for the transaction Coordinator, Terminator, etc.) -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1654) Extend TransactionImpl
Extend TransactionImpl -- Key: JBAS-1654 URL: http://jira.jboss.com/jira/browse/JBAS-1654 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Extend TransactionImpl so that it knows about the following DTM objects: Coordinator, Resource, and RecoveryCoordinator. Besides having a list of XA resources, a TransactionImpl instance will have a list of DTM Resources, each of which represents either a JBoss remoting-based resource or a (properly wrapped) OTS resource. It may also have a parent coordinator, which will be a DTM Coordinator (either a remoting-based coordinator or an OTS coordinator). If if has a parent coordinator, it must register itself as a Resource with that coordinator. The TransactionImpl must drive the 2PC across all XA resources and DTM resources. Logging and recovery are not included in this step. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1655) Add to TransactionImpl a method that enlists a DTM Resource...
Add to TransactionImpl a method that enlists a DTM Resource... -- Key: JBAS-1655 URL: http://jira.jboss.com/jira/browse/JBAS-1655 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Ensure that TransactionImpl has methods that do the actual work for all OTS/DTM objects and for XATerminator. Most of the needed methods already are in place, but some need to be added (e.g., a method to enlist a DTM Resource). -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1656) Implement UserTransaction over JBoss remoting
Implement UserTransaction over JBoss remoting - Key: JBAS-1656 URL: http://jira.jboss.com/jira/browse/JBAS-1656 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1657) Preliminary UserTransaction and 2PC tests
Preliminary UserTransaction and 2PC tests - Key: JBAS-1657 URL: http://jira.jboss.com/jira/browse/JBAS-1657 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Preliminary tests, still with no logging/recovery. Test UserTransaction over JBoss remoting. (UserTransaction over IIOP is already in place and has its own testcase.) Test 2PC across DTM Resources (either remoting-based and OTS-based) and XA resources. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1658) Change LocalId/GlobalId/Xid generation
Change LocalId/GlobalId/Xid generation -- Key: JBAS-1658 URL: http://jira.jboss.com/jira/browse/JBAS-1658 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Change the LocalId/GlobalId/Xid generation strategy so that the nextLocalId is not reset to 0 at server startup. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1659) Implement write-ahead logging for the distributed case
Implement write-ahead logging for the distributed case -- Key: JBAS-1659 URL: http://jira.jboss.com/jira/browse/JBAS-1659 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Resource and RecoveryCoordinator references must be logged. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1660) Implement recovery for the distributed case
Implement recovery for the distributed case --- Key: JBAS-1660 URL: http://jira.jboss.com/jira/browse/JBAS-1660 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1661) Test recovery
Test recovery - Key: JBAS-1661 URL: http://jira.jboss.com/jira/browse/JBAS-1661 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assigned to: Francisco Reverbel This task will be split in several sub-tasks. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1647) Provide JBoss remoting-based implementations of the DTM interfaces
[ http://jira.jboss.com/jira/browse/JBAS-1647?page=history ] Francisco Reverbel resolved JBAS-1647: -- Resolution: Done Provide JBoss remoting-based implementations of the DTM interfaces -- Key: JBAS-1647 URL: http://jira.jboss.com/jira/browse/JBAS-1647 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel The implementations will delegate the actual work to TransactionImpl instances. Besides the similarity in their interfaces, remoting-based DTM objects (Resource, Coordinator, etc.) must be similar to OTS objects also in that their references (proxies) are convertible to strings and vice-versa. This will be needed for logging. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1646) Define OTS-like interfaces for the DTM
[ http://jira.jboss.com/jira/browse/JBAS-1646?page=history ] Francisco Reverbel resolved JBAS-1646: -- Resolution: Done Define OTS-like interfaces for the DTM -- Key: JBAS-1646 URL: http://jira.jboss.com/jira/browse/JBAS-1646 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel Define OTS-like interfaces for the following DTM objects associated with a given transaction: Terminator, Coordinator, Resource, Synchronization, and RecoveryCoordinator. These interfaces allow those objects to be manipulated in a unified way, regardless of whether they are accessible via JBoss remoting or via CORBA/IIOP. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1648) Complete the existing implementation of the OTS interfaces
[ http://jira.jboss.com/jira/browse/JBAS-1648?page=history ] Francisco Reverbel resolved JBAS-1648: -- Resolution: Done Complete the existing implementation of the OTS interfaces -- Key: JBAS-1648 URL: http://jira.jboss.com/jira/browse/JBAS-1648 Project: JBoss Application Server Type: Sub-task Components: Transaction Manager service Versions: JBossAS-5.0 Alpha Reporter: Francisco Reverbel Assignee: Francisco Reverbel The existing OTS servant does not yet implements register_resource, recreate, and replay_completion. The implementation of those methods will delegate the actual work to the TransactionImpl instance the represents the transaction. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1649) Write OTS wrappers
[ http://jira.jboss.com/jira/browse/JBAS-1649?page=history ] Francisco Reverbel resolved JBAS-1649: -- Resolution: Done Write OTS wrappers -- Key: JBAS-1649 URL: http://jira.jboss.com/jira/browse/JBAS-1649 Project: JBoss Application Server Type: Sub-task Reporter: Francisco Reverbel Assignee: Francisco Reverbel Write some trivial OTS wrappers that implement the DTM interfaces by delegating the work to OTS objects. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1617) Merge fixes for JacORB bugs #562 and #568 into the JacORB lib shipped w/ JBoss
[ http://jira.jboss.com/jira/browse/JBAS-1617?page=history ] Francisco Reverbel resolved JBAS-1617: -- Resolution: Done The JacORB libraries have been updated to a patched version of JacORB 2.2.1, which identifies itself as JacORB V 2.2.1 (JBoss patch 2). This version fixes the following JacORB bugs: #445, #532, #550, #558, #562, #566, #568, #574, #584, #585, and #586. It also includes the exception reporting improvements committed to JacORB's CVS repository in 2004/11/18 and 2004/12/11. The updated libraries have been committed to CVS HEAD, Branch_4_0, and Branch_3_2. Merge fixes for JacORB bugs #562 and #568 into the JacORB lib shipped w/ JBoss -- Key: JBAS-1617 URL: http://jira.jboss.com/jira/browse/JBAS-1617 Project: JBoss Application Server Type: Task Components: IIOP service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.0 Final, JBossAS-3.2.6 Final, JBossAS-3.2.5 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1 Reporter: Francisco Reverbel Assignee: Francisco Reverbel Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final, JBossAS-5.0 Beta, JBossAS-5.0 Final, JBossPOJOServer-1.0 Alpha, JBossPOJOServer-1.0 Final, JBossAS-3.2.8 Final Original Estimate: 2 hours Remaining: 2 hours Merge fixes for bugs numberered 562 and 568 in JacORB's bugzilla. The fixes were submitted by Jimmy Wilson and are already in JacORB's CVS repository. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1617) Merge fixes for JacORB bugs #562 and #568 into the JacORB lib shipped w/ JBoss
[ http://jira.jboss.com/jira/browse/JBAS-1617?page=history ] Francisco Reverbel closed JBAS-1617: Merge fixes for JacORB bugs #562 and #568 into the JacORB lib shipped w/ JBoss -- Key: JBAS-1617 URL: http://jira.jboss.com/jira/browse/JBAS-1617 Project: JBoss Application Server Type: Task Components: IIOP service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.0 Final, JBossAS-3.2.6 Final, JBossAS-3.2.5 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1 Reporter: Francisco Reverbel Assignee: Francisco Reverbel Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final, JBossAS-5.0 Beta, JBossAS-5.0 Final, JBossPOJOServer-1.0 Alpha, JBossPOJOServer-1.0 Final, JBossAS-3.2.8 Final Original Estimate: 2 hours Time Spent: 3 hours Remaining: 0 minutes Merge fixes for bugs numberered 562 and 568 in JacORB's bugzilla. The fixes were submitted by Jimmy Wilson and are already in JacORB's CVS repository. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1617) Merge fixes for JacORB bugs #562 and #568 into the JacORB lib shipped w/ JBoss
Merge fixes for JacORB bugs #562 and #568 into the JacORB lib shipped w/ JBoss -- Key: JBAS-1617 URL: http://jira.jboss.com/jira/browse/JBAS-1617 Project: JBoss Application Server Type: Task Components: IIOP service Versions: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-4.0.1RC1, JBossAS-4.0.0 Final, JBossAS-3.2.5 Final Reporter: Francisco Reverbel Assigned to: Francisco Reverbel Fix For: JBossAS-4.0.2 Final, JBossPOJOServer-1.0 Alpha, JBossAS-5.0 Alpha, JBossPOJOServer-1.0 Final, JBossAS-5.0 Beta, JBossAS-5.0 Final, JBossAS-3.2.8 Final Merge fixes for bugs numberered 562 and 568 in JacORB's bugzilla. The fixes were submitted by Jimmy Wilson and are already in JacORB's CVS repository. -- 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 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jts removal and tyrex plugin status
I have removed from CVS HEAD all the stuff under thirdparty/sun-jts. File thirdparty/sun-jts/lib/jts.jar contained a bogus implementation of the standard class org.omg.CosTransactions.PropagationContextHelper. It had hardwired references to the Exolab class org.openorb.CORBA.Any. This is nonsense. An org.omg class should never have a dependency on a proprietary class. Even though jts.jar was under sun-jts, it looks like Exolab (Tyrex) stuff. I noticed that there was something weird about jts.jar because the new IIOP transaction code in HEAD didn't work with it. The tyrex plugin is the only module using the deleted jar. I have disabled the compilation of this plugin. Unless somebody steps up to fix and maintain the tyrex plugin, this module will be removed from CVS HEAD in a couple of weeks. Regards, Francisco --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Changes for IIOP over SSL
In order to support IIOP over SSL I have made (still uncommitted) changes to a couple of classes in the security module: - org.jboss.security.ssl.DomainServerSocketFactory Work currently performed within private method initSSLContext() factored out to an utility class, in order to be available to the IIOP/SSL code. - org.jboss.security.plugins.JaasSecurityDomain Work currently performed within start() method moved to create(). Reason: the JaasSecurityDomain must be ready when ORB.init() is called. CorbaOrbService calls ORB.init() within createService(), and this call cannot be moved to startService(), as the IIOP proxy factory (IORFactory) needs the IIOP invoker ready before that. Does anybody see some problem with these changes? If nobody speaks up, I'll commit them to CVS, along with IIOP over SSL support. Cheers, Francisco --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS problem
Thanks! Francisco On Sat, 27 Dec 2003, Scott M Stark wrote: The thirdparty directory is just a collection of other alias checkouts. You already had avalon checked into the thirdparty/apache/avalon dir in 3.2, so checkout thirdparty/apache/avalon on head and add the libs. I have done this and added a new alias to the _jboss_thirdparty so add the apache-avalon to your thirdparty tree using: [EMAIL PROTECTED] thirdparty]$ cvs co _thirdparty_apache_avalon cvs server: Updating apache-avalon cvs server: Updating apache-avalon/lib U apache-avalon/lib/README U apache-avalon/lib/avalon-framework.jar [EMAIL PROTECTED] thirdparty]$ ls apache-avalon/lib/ CVS/ README avalon-framework.jar Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francisco Reverbel Sent: Saturday, December 27, 2003 9:34 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] CVS problem jboss-head, fresh checkout: $ cd jboss-head/thirdparty $ mkdir apache-avalon $ cvs -z3 add apache-avalon cvs [add aborted]: cannot add to /cvsroot/jboss/CVSROOT/Emptydir $ cat CVS/Reposit --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS problem
jboss-head, fresh checkout: $ cd jboss-head/thirdparty $ mkdir apache-avalon $ cvs -z3 add apache-avalon cvs [add aborted]: cannot add to /cvsroot/jboss/CVSROOT/Emptydir $ cat CVS/Repository CVSROOT/Emptydir $ echo $CVSROOT :ext:[EMAIL PROTECTED]:/cvsroot/jboss What is this? Cheers, Francisco --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.2.3RC1
Me too, just updated jacorb.jar in thirdparty. Francisco On Sat, 8 Nov 2003, Alexey Loubyansky wrote: I am done for this RC. Scott M Stark wrote: When can these be committed? --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 3.2.3RC1
I am not aware of such problem... Cheers, Francisco On Fri, 7 Nov 2003, Sacha Labourey wrote: Will this contain the fix for the problem that occurs when doing invocation from JacORB against Orbix as well? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francisco Reverbel Sent: jeudi, 6. novembre 2003 23:25 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] 3.2.3RC1 When will you get 3.2.3.RC1 from CVS? There has been a JacORB bug fix (for Arjuna) that is not in our CVS yet. I´d generate a patched version of jacorb.jar with the fix. Cheers, Francisco On Wed, 5 Nov 2003, Scott M Stark wrote: I'm putting together a 3.2.3RC1 release to pickup some recent bug fixes. I'm working on a fix for [ 832561 ] NoSuchMethodException when HAJNDI joins cluster that I want to include. If there are any other must have fixes let me know. -- Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 3.2.3RC1
Bug #398 is the same as bug #365, which has been fixed before beta 2: http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=365 The fix is already included in the jacorb.jar library distributed with JBoss 3.2.2. CSIv2 is also there, but I didn't test it yet. We should try it as the basis for interoperable EJB security. Cheers, Francisco On Fri, 7 Nov 2003, Sacha Labourey wrote: I think it is this one: http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=398 Do you know if your release will include it? It seems to be part of beta 3. Do you know what is the status of Jacorb WRT csiv2? Cheers, sacha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francisco Reverbel Sent: vendredi, 7. novembre 2003 12:34 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] 3.2.3RC1 I am not aware of such problem... Cheers, --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.2.3RC1
When will you get 3.2.3.RC1 from CVS? There has been a JacORB bug fix (for Arjuna) that is not in our CVS yet. I´d generate a patched version of jacorb.jar with the fix. Cheers, Francisco On Wed, 5 Nov 2003, Scott M Stark wrote: I'm putting together a 3.2.3RC1 release to pickup some recent bug fixes. I'm working on a fix for [ 832561 ] NoSuchMethodException when HAJNDI joins cluster that I want to include. If there are any other must have fixes let me know. -- Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX DR3 rollback commit
Actually my rant was not well founded. Just run all IIOP tests on on HEAD (fresh checkout), with no errors. I don't understand why there were IIOP errors in the results Tom posted. (Perhaps his server run with the default config, rather than with the all config?) Cheers, Francisco On Tue, 21 Oct 2003, Tom Elrod wrote: Per request, I am going to wait an extra day before doing commit. Am also assuming that the post below is not an objection to the commit, but a well founded rant. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Francisco Reverbel Sent: Monday, October 20, 2003 4:21 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX DR3 rollback commit Guys, The test results Tom posted show IIOP tests failing on HEAD. I understand this is not his fault, as his changes were not yet merged into HEAD when the tests were run. Anyway, I've fixed IIOP in HEAD less than a month ago. All IIOP tests were running with no errors back then. rant I'm tired of chasing errors before doing IIOP work on HEAD. /rant Cheers, Francisco On Sun, 19 Oct 2003, Tom Elrod wrote: Hello all. I have been working on bringing in the source code from the jmx project from the Branch_4_0_DR3 into HEAD. This is needed since it is compliant with JMX 1.2, which is needed for some of the other modules (like JMX Remoting). Everything under the jmx directory will be updated, except the mx.loading module, which will remain the same as what is in HEAD now. In the process of migrating this code, many other classes had to be changed outside the jmx project, so that they would use any new API. I have run the testsuite (along with many other tests) to makes sure I did not break anything in the process. However, there is too much to be able to go through all the different modules. In general, the test results seem to reflect that not much (if anything) has been broken (see below) due to the change. I plan on committing all the code tomorrow (Monday) night around 11pm EST. Please review the following test results and verify I did not break anything significant in your module. You can follow the links at the bottom to get details on the exact tests that failed. In the following results, the repos named 'rollback' is the one that I have made the changes to and thus the one to be most aware of. Please let me know if there is something that needs to be corrected before I perform the commit tomorrow. BTW, there are not currently test results for 'rollback' on Linux, so that is why it is not filled in yet. Thanks. -Tom Windows 2000 \build\build.bat clean most Source Repos Test Results Branch_4_0_DR3success HEAD success rollback success \jmx\build.bat test-compliance-full-JBossMX test-implementation test-performance-JBossMX test-serialization test-stress-JBossMX Source Repos Test Target Test Results Branch_4_0_DR3test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 HEAD test-compliance-full-JBossMXTests run: 706, Failures: 3, Errors: 0 rollback test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 Branch_4_0_DR3test-implementation Tests run: 67, Failures: 1, Errors: 1 HEAD test-implementation OK (37 tests) rollback test-implementation Tests run: 67, Failures: 1, Errors: 1 Branch_4_0_DR3test-performance-JBossMXOK (14 tests) HEAD test-performance-JBossMXOK (11 tests) rollback test-performance-JBossMXOK (14 tests) Branch_4_0_DR3test-serialization Tests run: 93, Failures: 1, Errors: 0 HEAD test-serialization Tests run: 93, Failures: 0, Errors: 90 rollback test-serialization Tests run: 93, Failures: 1, Errors: 1 Branch_4_0_DR3test-stress-JBossMX OK (1 tests) HEAD test-stress-JBossMX OK (1 test) rollback test-stress-JBossMX OK (1 test) \testsuite\build.bat tests Source Repos TestFailuresErrors Success rateTime Branch_4_0_DR3847 13 480 41.79% 5817.237 HEAD 733 54 304 51.16% 1687.185 rollback 718 62 308 48.47 1656.592 Linux - Red Hat 7.3 \build\build.sh clean most Source Repos Test Results Branch_4_0_DR3success HEAD success rollback \jmx\build.sh test-compliance-full-JBossMX test-implementation test-performance-JBossMX test-serialization test-stress-JBossMX Source Repos Test Target Test Results Branch_4_0_DR3test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 HEAD test-compliance-full-JBossMXTests run: 706, Failures: 3
RE: [JBoss-dev] JMX DR3 rollback commit
You're right, Tom. My post was not an objection to the commit. BTW: Thank you for your great work on the remoting framework! Cheers, Francisco On Tue, 21 Oct 2003, Tom Elrod wrote: Per request, I am going to wait an extra day before doing commit. Am also assuming that the post below is not an objection to the commit, but a well founded rant. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Francisco Reverbel Sent: Monday, October 20, 2003 4:21 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX DR3 rollback commit Guys, The test results Tom posted show IIOP tests failing on HEAD. I understand this is not his fault, as his changes were not yet merged into HEAD when the tests were run. Anyway, I've fixed IIOP in HEAD less than a month ago. All IIOP tests were running with no errors back then. rant I'm tired of chasing errors before doing IIOP work on HEAD. /rant Cheers, Francisco On Sun, 19 Oct 2003, Tom Elrod wrote: Hello all. I have been working on bringing in the source code from the jmx project from the Branch_4_0_DR3 into HEAD. This is needed since it is compliant with JMX 1.2, which is needed for some of the other modules (like JMX Remoting). Everything under the jmx directory will be updated, except the mx.loading module, which will remain the same as what is in HEAD now. In the process of migrating this code, many other classes had to be changed outside the jmx project, so that they would use any new API. I have run the testsuite (along with many other tests) to makes sure I did not break anything in the process. However, there is too much to be able to go through all the different modules. In general, the test results seem to reflect that not much (if anything) has been broken (see below) due to the change. I plan on committing all the code tomorrow (Monday) night around 11pm EST. Please review the following test results and verify I did not break anything significant in your module. You can follow the links at the bottom to get details on the exact tests that failed. In the following results, the repos named 'rollback' is the one that I have made the changes to and thus the one to be most aware of. Please let me know if there is something that needs to be corrected before I perform the commit tomorrow. BTW, there are not currently test results for 'rollback' on Linux, so that is why it is not filled in yet. Thanks. -Tom Windows 2000 \build\build.bat clean most Source Repos Test Results Branch_4_0_DR3success HEAD success rollback success \jmx\build.bat test-compliance-full-JBossMX test-implementation test-performance-JBossMX test-serialization test-stress-JBossMX Source Repos Test Target Test Results Branch_4_0_DR3test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 HEAD test-compliance-full-JBossMXTests run: 706, Failures: 3, Errors: 0 rollback test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 Branch_4_0_DR3test-implementation Tests run: 67, Failures: 1, Errors: 1 HEAD test-implementation OK (37 tests) rollback test-implementation Tests run: 67, Failures: 1, Errors: 1 Branch_4_0_DR3test-performance-JBossMXOK (14 tests) HEAD test-performance-JBossMXOK (11 tests) rollback test-performance-JBossMXOK (14 tests) Branch_4_0_DR3test-serialization Tests run: 93, Failures: 1, Errors: 0 HEAD test-serialization Tests run: 93, Failures: 0, Errors: 90 rollback test-serialization Tests run: 93, Failures: 1, Errors: 1 Branch_4_0_DR3test-stress-JBossMX OK (1 tests) HEAD test-stress-JBossMX OK (1 test) rollback test-stress-JBossMX OK (1 test) \testsuite\build.bat tests Source Repos TestFailuresErrors Success rateTime Branch_4_0_DR3847 13 480 41.79% 5817.237 HEAD 733 54 304 51.16% 1687.185 rollback 718 62 308 48.47 1656.592 Linux - Red Hat 7.3 \build\build.sh clean most Source Repos Test Results Branch_4_0_DR3success HEAD success rollback \jmx\build.sh test-compliance-full-JBossMX test-implementation test-performance-JBossMX test-serialization test-stress-JBossMX Source Repos Test Target Test Results Branch_4_0_DR3test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 HEAD test-compliance-full-JBossMXTests run: 706, Failures: 3, Errors: 0 rollback test-compliance-full-JBossMX Branch_4_0_DR3test-implementation Tests run: 67, Failures: 1, Errors: 1
Re: [JBoss-dev] JMX DR3 rollback commit
Guys, The test results Tom posted show IIOP tests failing on HEAD. I understand this is not his fault, as his changes were not yet merged into HEAD when the tests were run. Anyway, I've fixed IIOP in HEAD less than a month ago. All IIOP tests were running with no errors back then. rant I'm tired of chasing errors before doing IIOP work on HEAD. /rant Cheers, Francisco On Sun, 19 Oct 2003, Tom Elrod wrote: Hello all. I have been working on bringing in the source code from the jmx project from the Branch_4_0_DR3 into HEAD. This is needed since it is compliant with JMX 1.2, which is needed for some of the other modules (like JMX Remoting). Everything under the jmx directory will be updated, except the mx.loading module, which will remain the same as what is in HEAD now. In the process of migrating this code, many other classes had to be changed outside the jmx project, so that they would use any new API. I have run the testsuite (along with many other tests) to makes sure I did not break anything in the process. However, there is too much to be able to go through all the different modules. In general, the test results seem to reflect that not much (if anything) has been broken (see below) due to the change. I plan on committing all the code tomorrow (Monday) night around 11pm EST. Please review the following test results and verify I did not break anything significant in your module. You can follow the links at the bottom to get details on the exact tests that failed. In the following results, the repos named 'rollback' is the one that I have made the changes to and thus the one to be most aware of. Please let me know if there is something that needs to be corrected before I perform the commit tomorrow. BTW, there are not currently test results for 'rollback' on Linux, so that is why it is not filled in yet. Thanks. -Tom Windows 2000 \build\build.bat clean most Source Repos Test Results Branch_4_0_DR3success HEAD success rollback success \jmx\build.bat test-compliance-full-JBossMX test-implementation test-performance-JBossMX test-serialization test-stress-JBossMX Source Repos Test Target Test Results Branch_4_0_DR3test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 HEAD test-compliance-full-JBossMXTests run: 706, Failures: 3, Errors: 0 rollback test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 Branch_4_0_DR3test-implementation Tests run: 67, Failures: 1, Errors: 1 HEAD test-implementation OK (37 tests) rollback test-implementation Tests run: 67, Failures: 1, Errors: 1 Branch_4_0_DR3test-performance-JBossMXOK (14 tests) HEAD test-performance-JBossMXOK (11 tests) rollback test-performance-JBossMXOK (14 tests) Branch_4_0_DR3test-serialization Tests run: 93, Failures: 1, Errors: 0 HEAD test-serialization Tests run: 93, Failures: 0, Errors: 90 rollback test-serialization Tests run: 93, Failures: 1, Errors: 1 Branch_4_0_DR3test-stress-JBossMX OK (1 tests) HEAD test-stress-JBossMX OK (1 test) rollback test-stress-JBossMX OK (1 test) \testsuite\build.bat tests Source Repos TestFailuresErrors Success rateTime Branch_4_0_DR3847 13 480 41.79% 5817.237 HEAD 733 54 304 51.16% 1687.185 rollback 718 62 308 48.47 1656.592 Linux - Red Hat 7.3 \build\build.sh clean most Source Repos Test Results Branch_4_0_DR3success HEAD success rollback \jmx\build.sh test-compliance-full-JBossMX test-implementation test-performance-JBossMX test-serialization test-stress-JBossMX Source Repos Test Target Test Results Branch_4_0_DR3test-compliance-full-JBossMXTests run: 926, Failures: 4, Errors: 2 HEAD test-compliance-full-JBossMXTests run: 706, Failures: 3, Errors: 0 rollback test-compliance-full-JBossMX Branch_4_0_DR3test-implementation Tests run: 67, Failures: 1, Errors: 1 HEAD test-implementation OK (37 tests) rollback test-implementation Branch_4_0_DR3test-performance-JBossMXOK (14 tests) HEAD test-performance-JBossMXOK (11 tests) rollback test-performance-JBossMX Branch_4_0_DR3test-serialization Tests run: 93, Failures: 1, Errors: 0 HEAD test-serialization Tests run: 93, Failures: 0, Errors: 90 rollback test-serialization Branch_4_0_DR3test-stress-JBossMX OK (1 tests) HEAD test-stress-JBossMX OK (1 test) rollback test-stress-JBossMX \testsuite\build.sh tests Source Repos TestFailuresErrors Success rateTime Branch_4_0_DR3850 12 479 42.24% 3711.145 HEAD 777 57 331 50.06% 1779.778 rollback The complete testsuite
[JBoss-dev] Missing package info for app classes deployed in HEAD
IIOP tests are currently broken in HEAD. The RMI/IIOP analysis and stub generation code calls cls.getPackage(). The tests break because getPackage() is returning null on application-defined classes. If I print out the class and the package of an application class, I get something like cls = class org.jboss.test.bankiiop.interfaces.AccountData pkg = null Non-application classes, however, still have package info: cls = interface javax.ejb.Handle pkg = package javax.ejb, JBoss, version 4.0.0 cls = interface javax.ejb.EJBObject pkg = package javax.ejb, JBoss, version 4.0.0 According to the getPackage() documentation, the method returns null if no package object was created by the class loader of the target class. Looks like this problem is related with the bytecode enhancement performed at load time. Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jboss-group] Re: [JBoss-dev] Missing package info for app classes deployed in HEAD
Thanks, Adrian. It is not urgent, I am not working anymore today. If you point me to the file that misses a definePackage(), I'll add it myself next time I find some time to work on JBoss. Unless you do it before me, of course. Cheers, Francisco On 19 Sep 2003, Adrian Brock wrote: The defineClass() is missing a definePackage() see the hack in AOP's standalone system classloader. I can fix it later if it isn't urgent. This needs improving as it does not retrieve manifest information. Regards, Adrian On Fri, 2003-09-19 at 22:49, Francisco Reverbel wrote: IIOP tests are currently broken in HEAD. The RMI/IIOP analysis and stub generation code calls cls.getPackage(). The tests break because getPackage() is returning null on application-defined classes. If I print out the class and the package of an application class, I get something like cls = class org.jboss.test.bankiiop.interfaces.AccountData pkg = null Non-application classes, however, still have package info: cls = interface javax.ejb.Handle pkg = package javax.ejb, JBoss, version 4.0.0 cls = interface javax.ejb.EJBObject pkg = package javax.ejb, JBoss, version 4.0.0 According to the getPackage() documentation, the method returns null if no package object was created by the class loader of the target class. Looks like this problem is related with the bytecode enhancement performed at load time. Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC ___ jboss-group mailing list [EMAIL PROTECTED] http://mail.jboss.org/mailman/listinfo/jboss-group --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Build failing on Branch_3_2
Fresh checkout. The build.sh script fails with this error: compile-classes: [javac] Compiling 584 source files to /usr/local/reverbel/jboss-3.2/server/output/classes /usr/local/reverbel/jboss-3.2/server/output/gen-src/org/jboss/invocation/local/LocalInvokerMBean.java:10: '}' expected ^ 1 error BUILD FAILED Does anybody else see this? Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build failing on Branch_3_2
Java 1.4.2 on Debian 3.0 (woody). I am using an old Linux kernel, though. $ java -version java version 1.4.2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) $ uname -a Linux pong 2.2.19 #1 SMP Wed Oct 17 08:56:33 BRST 2001 i686 unknown Francisco On Wed, 10 Sep 2003, Scott M Stark wrote: No, I just did a checkout and build of 3.2 using 1.4.2 on RH9. What compiler and OS are you using? Francisco Reverbel wrote: Fresh checkout. The build.sh script fails with this error: compile-classes: [javac] Compiling 584 source files to /usr/local/reverbel/jboss-3.2/server/output/classes /usr/local/reverbel/jboss-3.2/server/output/gen-src/org/jboss/invocation/local/LocalInvokerMBean.java:10: '}' expected ^ 1 error BUILD FAILED Does anybody else see this? Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build failing on Branch_3_2
It works after I removed file output/gen-src/org/jboss/invocation/local/LocalInvokerMBean.java which was incomplete. This file has not been fully generated due to an out of memory error in a previous run of build.sh. Thanks, Francisco On Wed, 10 Sep 2003, Scott M Stark wrote: No, I just did a checkout and build of 3.2 using 1.4.2 on RH9. What compiler and OS are you using? Francisco Reverbel wrote: Fresh checkout. The build.sh script fails with this error: compile-classes: [javac] Compiling 584 source files to /usr/local/reverbel/jboss-3.2/server/output/classes /usr/local/reverbel/jboss-3.2/server/output/gen-src/org/jboss/invocation/local/LocalInvokerMBean.java:10: '}' expected ^ 1 error BUILD FAILED Does anybody else see this? Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build failing on Branch_3_2
Thanks, Adrian. You're right, the error does not happen in a clean build. I have been getting out of memory errors from clean builds. Xdoclet... My second attempt typically succeeds. This time, however, the clean build left me with an incomplete source file. Cheers, Francisco On 10 Sep 2003, Adrian Brock wrote: Hi Francisco, It looks like xdoclet screwed up at some point. This is generated source. Do you get the same error if you ./build.sh clean before rebuilding? Regards, Adrian On Wed, 2003-09-10 at 16:14, Francisco Reverbel wrote: Java 1.4.2 on Debian 3.0 (woody). I am using an old Linux kernel, though. $ java -version java version 1.4.2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) $ uname -a Linux pong 2.2.19 #1 SMP Wed Oct 17 08:56:33 BRST 2001 i686 unknown Francisco On Wed, 10 Sep 2003, Scott M Stark wrote: No, I just did a checkout and build of 3.2 using 1.4.2 on RH9. What compiler and OS are you using? Francisco Reverbel wrote: Fresh checkout. The build.sh script fails with this error: compile-classes: [javac] Compiling 584 source files to /usr/local/reverbel/jboss-3.2/server/output/classes /usr/local/reverbel/jboss-3.2/server/output/gen-src/org/jboss/invocation/local/LocalInvokerMBean.java:10: '}' expected ^ 1 error BUILD FAILED Does anybody else see this? Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RMI-IIOP type restrictions
Hi Adam, On Mon, 11 Aug 2003, Adam Wasserman wrote: Hello all, I am using JBoss 3.2.1 and would like to deploy a stateless session bean using the iiop invoker. The remote interface of this bean makes use of an object with a reference to an array of java.util.Map objects. During deployment, JBoss performs an interface analysis on the remote interface. I'm not very knowledgeable in this area yet, but I imagine that JBoss is busy verifying all the types referenced directly or indirectly by the object referenced in the remote interface and producing IDL definitions for them. This deployment process always fails, and it is failing on the reference to the array of java.util.Map: private Map[] hoursPerProjectPerDay; The exception I get can be found at the end of this posting. If I change the reference to: private HashMap[] hoursPerProjectPerDay; there is no problem at deployment time. Am I violating a type restriction in IDL? No you are not. You have found a bug in JBoss/IIOP. I'm looking into it... Cheers, Francisco Many thanks, Adam 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ParameterAnalysis] ParameterAnalysis(): cls=[java.util.Map] typeIDLName=[::java::util::Map]. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerImplDelegate._lookup(java) entered. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerImplDelegate._lookup(util) entered. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerDelegateImpl.add() added util. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ContainerAnalysis] Interface count: 0 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ValueDefImpl] ValueDefImpl.type() entered. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ValueDefImpl] ValueDefImpl.type() returning. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.InterfaceRepository] Value: base=Map 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerDelegateImpl.add() added Map. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ContainerAnalysis] Constants count: 0 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.InterfaceRepository] Value member count: 0 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ContainerAnalysis] Attribute count: 1 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerDelegateImpl.add() added Empty. 2003-08-11 15:03:16,273 ERROR [org.jboss.ejb.StatelessSessionContainer] Initialization failed java.lang.NullPointerException at org.jboss.iiop.rmi.ir.InterfaceRepository.addArray(InterfaceRepository.java:806) at org.jboss.iiop.rmi.ir.InterfaceRepository.addClass(InterfaceRepository.java:703) at org.jboss.iiop.rmi.ir.InterfaceRepository.getTypeCode(InterfaceRepository.java:311) at org.jboss.iiop.rmi.ir.InterfaceRepository.addValue(InterfaceRepository.java:965) at org.jboss.iiop.rmi.ir.InterfaceRepository.addClass(InterfaceRepository.java:729) at org.jboss.iiop.rmi.ir.InterfaceRepository.getTypeCode(InterfaceRepository.java:311) at org.jboss.iiop.rmi.ir.InterfaceRepository.addOperations(InterfaceRepository.java:650) at org.jboss.iiop.rmi.ir.InterfaceRepository.addInterface(InterfaceRepository.java:898) at org.jboss.iiop.rmi.ir.InterfaceRepository.addClass(InterfaceRepository.java:710) at org.jboss.iiop.rmi.ir.InterfaceRepository.getTypeCode(InterfaceRepository.java:311) at org.jboss.iiop.rmi.ir.InterfaceRepository.mapClass(InterfaceRepository.java:137) at org.jboss.proxy.ejb.IORFactory.create(IORFactory.java:251) at org.jboss.ejb.StatelessSessionContainer.createService(StatelessSessionContainer.java:164) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:158) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy8.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:310) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at
Re: [JBoss-dev] RMI-IIOP type restrictions
This bug is fixed in CVS Branch_3_2. It affected arrays whose element type corresponds (per the Java to IDL mapping) to an abstract valuetype. BTW: Adam's workaround was effective because he replaced an abstract valuetype (java.util.Map) by a concrete one (java.util.HashMap). Cheers, Francisco On Wed, 13 Aug 2003, Francisco Reverbel wrote: Hi Adam, On Mon, 11 Aug 2003, Adam Wasserman wrote: Hello all, I am using JBoss 3.2.1 and would like to deploy a stateless session bean using the iiop invoker. The remote interface of this bean makes use of an object with a reference to an array of java.util.Map objects. During deployment, JBoss performs an interface analysis on the remote interface. I'm not very knowledgeable in this area yet, but I imagine that JBoss is busy verifying all the types referenced directly or indirectly by the object referenced in the remote interface and producing IDL definitions for them. This deployment process always fails, and it is failing on the reference to the array of java.util.Map: private Map[] hoursPerProjectPerDay; The exception I get can be found at the end of this posting. If I change the reference to: private HashMap[] hoursPerProjectPerDay; there is no problem at deployment time. Am I violating a type restriction in IDL? No you are not. You have found a bug in JBoss/IIOP. I'm looking into it... Cheers, Francisco Many thanks, Adam 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ParameterAnalysis] ParameterAnalysis(): cls=[java.util.Map] typeIDLName=[::java::util::Map]. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerImplDelegate._lookup(java) entered. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerImplDelegate._lookup(util) entered. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerDelegateImpl.add() added util. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ContainerAnalysis] Interface count: 0 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ValueDefImpl] ValueDefImpl.type() entered. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ValueDefImpl] ValueDefImpl.type() returning. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.InterfaceRepository] Value: base=Map 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerDelegateImpl.add() added Map. 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ContainerAnalysis] Constants count: 0 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.InterfaceRepository] Value member count: 0 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ContainerAnalysis] Attribute count: 1 2003-08-11 15:03:16,273 DEBUG [org.jboss.iiop.rmi.ir.ContainerImplDelegate] ContainerDelegateImpl.add() added Empty. 2003-08-11 15:03:16,273 ERROR [org.jboss.ejb.StatelessSessionContainer] Initialization failed java.lang.NullPointerException at org.jboss.iiop.rmi.ir.InterfaceRepository.addArray(InterfaceRepository.java:806) at org.jboss.iiop.rmi.ir.InterfaceRepository.addClass(InterfaceRepository.java:703) at org.jboss.iiop.rmi.ir.InterfaceRepository.getTypeCode(InterfaceRepository.java:311) at org.jboss.iiop.rmi.ir.InterfaceRepository.addValue(InterfaceRepository.java:965) at org.jboss.iiop.rmi.ir.InterfaceRepository.addClass(InterfaceRepository.java:729) at org.jboss.iiop.rmi.ir.InterfaceRepository.getTypeCode(InterfaceRepository.java:311) at org.jboss.iiop.rmi.ir.InterfaceRepository.addOperations(InterfaceRepository.java:650) at org.jboss.iiop.rmi.ir.InterfaceRepository.addInterface(InterfaceRepository.java:898) at org.jboss.iiop.rmi.ir.InterfaceRepository.addClass(InterfaceRepository.java:710) at org.jboss.iiop.rmi.ir.InterfaceRepository.getTypeCode(InterfaceRepository.java:311) at org.jboss.iiop.rmi.ir.InterfaceRepository.mapClass(InterfaceRepository.java:137) at org.jboss.proxy.ejb.IORFactory.create(IORFactory.java:251) at org.jboss.ejb.StatelessSessionContainer.createService(StatelessSessionContainer.java:164) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:158) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy8.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:310
Re: [JBoss-dev] releasing on Sunday
All IIOP tests fail in the 4.0 branch. Does anybody know why? I thought there were no IIOP changes in head since it was branched off 3.x. There are some IIOP fixes in 3.2 that need to be merged into head. Following the usual test before, test after procedure, I run the tests before doing it, only to find out that IIOP was already broken. :-( Cheers, Francisco On Tue, 27 May 2003, Bill Burke wrote: We'll be doing the DR1 release on Sunday. Please ask Scott or me before committing. We'll be more and more reluctant to allow commits as we get closer. We should be stabalizing not adding new features at the last minute. Thanks, Bill Bill Burke Chief Architect JBoss Group, LLC Cast your vote for JBoss as JDJ Best App Server http://www.sys-con.com/java/readerschoice2003/vote.cfm --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 3.2 doesn't run on IBM JDK?
The 3.2 branch (fresh check out just taken from CVS) is giving me the exception below with IBM's VM on Linux. Shouldn't we fix this before 3.2 goes final? Cheers, Francisco - $ uname -a Linux pong 2.2.19 #1 SMP Wed Oct 17 08:56:33 BRST 2001 i686 unknown - $ java -version java version 1.4.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0) Classic VM (build 1.4.0, J2RE 1.4.0 IBM build cxia32140-20020917a (JIT enabled: jitc)) - $ ./run.sh ... [snip] 16:38:33,411 ERROR [MainDeployer] could not create deployment: file:/usr/local/reverbel/jboss-3.2/build/output/jboss-3.2.0RC5/server/default/conf/jboss-service.xml java.lang.NoClassDefFoundError: $Proxy0 at sun.reflect.GeneratedConstructorAccessor9.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:42) at java.lang.reflect.Constructor.newInstance(Constructor.java:299) at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:585) at org.jboss.system.ServiceController.getServiceProxy(ServiceController.java:739) at org.jboss.system.ServiceController.create(ServiceController.java:276) at org.jboss.system.ServiceController.create(ServiceController.java:243) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:40) at java.lang.reflect.Method.invoke(Method.java:335) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy5.create(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:207) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:784) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:639) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:597) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:61) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:40) at java.lang.reflect.Method.invoke(Method.java:335) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:361) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:268) at org.jboss.Main.boot(Main.java:159) at org.jboss.Main$1.run(Main.java:397) at java.lang.Thread.run(Thread.java:566) 16:38:33,504 ERROR [Server] Failed to start ...[snip] --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss_3_2.dtd updated
A protocol is associated with a reference (proxy) factory. My previous message stressed the protocol (invoker) rather than the proxy factory. The crucial thing is the reference factory, i.e., whether a remote reference is a serialized proxy or an IOR. Suppose method m of bean X returns some EJBObject. Moreover, suppose bean Y also has a method that returns an EJBObject, which bean Y obtains by calling m on X. - If a non-CORBA (JRMP/HTTP/SOAP/whatever) client written in Java calls bean Y to get an EJBObject, it receives a serialized proxy. - If a CORBA client (possibly written in C++) performs the same call on bean Y, it must receive an IOR. Serialized proxies give the EJB the freedom to return a serialized proxy that uses a protocol different from the one used by the current invocation. There is no such freedom with IIOP. You can still optimize local calls, but must use IORFactory, the IIOP-specific proxy factory. (Here I prefer the more general term reference factory). I would expect the same issue to appear for any standardized protocol that supports non-Java clients. Does it make sense for a Visual Basic client to get an EJBObject by interacting with an EJB via SOAP? If so (I don't really know), the EJBObject cannot be a serialized Java proxy. Cheers, Francisco On Tue, 4 Mar 2003, Scott M Stark wrote: I still don't understand why the incoming protocol should dictate the protocol that any invocations made the the target bean. If I'm bean X and some .NET clown invoked via soap, why do I want to in turn invoke the beans Y and Z through soap when I can use a local interface or optimized RMI? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Francisco Reverbel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 10:01 PM Subject: Re: [JBoss-dev] jboss_3_2.dtd updated These ejb-refs could have been defined outside of the invoker element. Invoker-specific ejb-refs make sense when you have multiple invokers per EJB. They are not really needed in the bankiiop testcase, which uses a single invoker (the IIOP invoker). I have probably placed them within the invoker element just because their jndi-names are IIOP-specific. If you have multiple invokers per EJB, invoker-specific ejb-refs act as a kind of multivalued link from the bean ENC to a set of JNDI names (one per invoker). Such a multivalued link allows outgoing invocations to be transparently performed through the same protocol (invoker) as the current invocation. The particular JNDI name seen at the end of the multivalued link depends on the invoker through which the current invocation arrived. The bean code just uses an ejb-ref, such as ejb/Bank. If the bean code runs within an IIOP invocation, ejb/Bank means iiop/bank/Bank, which is bound to a CORBA IOR. If the same code runs within a JRMP invocation, ejb/Bank could mean bank/Bank, which would be bound to a serialized JRMP proxy. Cheers, Francisco --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss_3_2.dtd updated
On Tue, 4 Mar 2003, Scott M Stark wrote: The jboss_3_2.dtd was way out of date with respect to the container invoker configuration so I updated it and checked it in. Take a look at this and see if there are other missing elements or elements that should be dropped. One construct that I don't understand in the invoker-bindings/invoker elements are the ejb-ref child elements. For example, this setup from the bankiiop testcase: session ejb-nameTeller/ejb-name jndi-namebank/Teller/jndi-name configuration-nameStandard Stateless SessionBean/configuration-name invoker-bindings invoker invoker-proxy-binding-nameiiop/invoker-proxy-binding-name ejb-ref ejb-ref-nameejb/Customer/ejb-ref-name jndi-nameiiop/bank/Customer/jndi-name /ejb-ref ejb-ref ejb-ref-nameejb/Account/ejb-ref-name jndi-nameiiop/bank/Account/jndi-name /ejb-ref ejb-ref ejb-ref-nameejb/Bank/ejb-ref-name jndi-nameiiop/bank/Bank/jndi-name /ejb-ref /invoker /invoker-bindings /session What is the purpose of the invoker binding specific ejb-refs? It still just a link from the bean ENC to a JNDI name so why are then under the invoker-bindings? These ejb-refs could have been defined outside of the invoker element. Invoker-specific ejb-refs make sense when you have multiple invokers per EJB. They are not really needed in the bankiiop testcase, which uses a single invoker (the IIOP invoker). I have probably placed them within the invoker element just because their jndi-names are IIOP-specific. If you have multiple invokers per EJB, invoker-specific ejb-refs act as a kind of multivalued link from the bean ENC to a set of JNDI names (one per invoker). Such a multivalued link allows outgoing invocations to be transparently performed through the same protocol (invoker) as the current invocation. The particular JNDI name seen at the end of the multivalued link depends on the invoker through which the current invocation arrived. The bean code just uses an ejb-ref, such as ejb/Bank. If the bean code runs within an IIOP invocation, ejb/Bank means iiop/bank/Bank, which is bound to a CORBA IOR. If the same code runs within a JRMP invocation, ejb/Bank could mean bank/Bank, which would be bound to a serialized JRMP proxy. Cheers, Francisco --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
You won't find this in the servlet spec. SomeClassName[some/object/id]/some/file/path is a JBoss convention for specifying Java classes and resources dynamically downloaded by clients. It is used by org.jboss.web.WebClassLoader and by org.jboss.iiop.WebCL. See comments in server/src/main/org/jboss/web/WebServer.java See also server/src/main/org/jboss/web/WebClassLoader.java iiop/src/main/org/jboss/iiop/WebCL.java Cheers, Francisco On Wed, 12 Feb 2003, James Cooley wrote: Hi Dain, Scott, I wrote a servlet that accepts a request from a java.net.URLClassLoader and returns the class. AFAIK I need only support requests of the kind org/jboss/util/stream/Streams.class but the exising WebServer class also supports SomeClassName[some/object/id]/some/file/path I can't find where this protocol is defined elsewhere - please point me at the spec if we need to support it - I'm a bit blind as to what we need as you can see from the next question ... I created a class-loader.war and I tried running the JRMP tests with ./testsuite/build.sh -Djava.rmi.server.codebase=http://localhost:8080/class-loader/ -Dtest=jrmp test but it doesn't work and I get ERROR [JRMPInvoker] Starting failed: java.rmi.server.ExportException: Port already in use: 4447; What am I doing wrong? How can I test this. James Dain Sundstrom wrote: We have a small project open for a volunteer. In Jboss 2 and 3 we have a custom lightweight web server (port 8083) that returns java class files from the classLoader.getResouceAsStream to RMI clients (this is how remote class loading happens). I talked to Scott at JBoss Boot Camp and we think it is a good idea to replace this with a plain old Servlet for JBoss 4.0 so it can work with regular security, pooling and such. This is a fairly simple piece of code and shouldn't take longer then a day or two. If you are interested the code can be found in jboss-head/server/src/main/org/jboss/web/WebServer.java -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remote class loading servlet
The IIOP tests also rely on remote class loading. They should still work after the simple web server is replaced by a servlet. (The *-iiop tests run on a server with configuration 'all'.) Cheers, Francisco On Fri, 7 Feb 2003, Scott M Stark wrote: There is a dynamic class loading unit test: org.jboss.test.jrmp.test.DynLoadingUnitTestCase Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 07, 2003 11:50 AM Subject: Re: [JBoss-dev] Remote class loading servlet On Friday, February 7, 2003, at 01:28 PM, James Cooley wrote: Dain Sundstrom wrote: Scott, I'm putting the question for you at the top, so you can see it. How do we specify the code base for remote loading? If James writes this he will need to change it to point to the servlet. James, You are way over thinking this. As I said there isn't a unit test for this so I guess it looked like it was doing more than it was doing in reality. Good idea. Can you add a unit test for this also? :) -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Transaction propagation change
On Tue, 21 Jan 2003, marc fleury wrote: And, finally, why did you tightly couple distributed tx logic with invoker's implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you've described but in invoker independent way? If only ole husgaard was awake :) I have been asking the same question for about a year and a half. I forgot the reason, which probably means it wasn't real, but Ole seemed to have one... Transaction propagation over IIOP is a reason. CORBA specifies that transaction info goes in the service context, which is a field of the IIOP request. Francisco --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
On Tue, 21 Jan 2003, David Jencks wrote: On Tuesday, January 21, 2003, at 09:43 AM, Francisco Reverbel wrote: On Tue, 21 Jan 2003, marc fleury wrote: And, finally, why did you tightly couple distributed tx logic with invoker's implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you've described but in invoker independent way? If only ole husgaard was awake :) I have been asking the same question for about a year and a half. I forgot the reason, which probably means it wasn't real, but Ole seemed to have one... Transaction propagation over IIOP is a reason. CORBA specifies that transaction info goes in the service context, which is a field of the IIOP request. Does this constrain non-iiop invokers in any way? I don't think so. Ideally it would be good if transaction propagation (i.e. all the code that inserts/extracts XIDs into/from invocation objects) were somehow encapsulated within a TxPropagator MBean, which would be specified by the contained configuration. Except for the IIOP invoker, all invokers would use the default TxPropagator MBean. The IIOP invoker would use an special tx propagator, which would insert/extract XIDs into/from IIOP service contexts. The idea of a default TxPropagator is similar to our ProxyFactory notion, in the sense that it works with all invokers but the IIOP invoker. The 3.2 container config includes a set of invoker/proxy bindings. Valid bindings are IIOPInvoker / IORFactory * / ProxyFactory (where * is any non-IIOP invoker) We could have invoker/proxy/txPropagator bindings instead: IIOPInvoker / IORFactory / IIOPTxPropagator * / ProxyFactory / TxPropagator Anyway, I don't think the IIOP case should constrain you from doing whatever needs to be done to have transactions propagated over non-IIOP protocols. Right now tx propagation over IIOP does not look like a prioritary thing, so I don't know if an IIOPTxPropagator will be written or not. Do we control anything about the client side of the iiop invoker? No. How about if the client is java rather than c++? In this case client-side stubs can (but are not required to) be dynamically downloaded from the server. Are there some short yet informative docs on how iiop into jboss works? No. I am planning to work on doco on February. Right now there is only the blurb in http://www.jboss.org/developers/projects/jboss/iiop.jsp, which applies to 3.0. (In 3.2 there were IIOP-related changes on the container config.) Do you have specific questions? Cheers, Francisco --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] error trying to run iiop tests
The one-test target does not work for IIOP tests, which require IIOP-related arguments to be passed to the JVM. To run IIOP tests, use the iiop-test target (runs all IIOP tests in a given directory) or the tests-iiop-stress target (runs all IIOP tests): testsuite/build.sh -Dtest=helloiiop -Dnojars=true iiop-test (Runs all IIOP tests in the helloiiop dir) testsuite/build.sh -Dnojars=true tests-iiop-stress (Runs all IIOP tests.) The -Dnojars=true switch may be omitted, I use it to avoid rebuilding the test jars every time. Cheers, Francisco On Thu, 14 Nov 2002, Emerson Cargnin - SICREDI Serviços wrote: I've tried to run iiop tests (in 3.0.5rc1 and 3.2beta2) through the command: ./build.sh -Dtest=org.jboss.test.helloiiop.test.HelloTimingStressTestCase one-test but it down't work, just get a classcast exception. i started with all conf -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Where is HttpInvoker?
I looked for Scott's HttpInvoker in HEAD and didn't find it there. Where is it? Cheers, Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] is pooling useless?
Well, if you are pooling fine grained objects you should not
use java.util.LinkedList to implement the pool. Whenever you
add an element to a LinkedList you are creating an auxiliary
Entry object, with fields `element', `next', and `previous'.
To do pooling of fine grained objects you should add a `next'
field to the objects you are pooling and use your own linked
list implementation. Otherwise you are trading the creation of
pooled objects by the creation of Entry objects plus the
sychronization cost. Not a good deal.
Some time ago I had to optimize critical-path code and a pool
of fine-grained objects (linked together by a `next' field within
each object) was very useful.
Cheers,
Francisco
On Wed, 11 Sep 2002, David Jencks wrote:
Pooling is mostly useful if the object holds an expensive resource such as
a database connection. For just plain data I think the synchronization
costs of pooling things tend to outweigh the construction costs of making
new ones pretty quickly. Ole recently removed the (pooled) TxCapsule in
favor of new-each-time TransactionImpl for this reason.
Your results are fun to contemplate, though.
david jencks
On 2002.09.10 23:59:40 -0400 Bill Burke wrote:
I was looking into pooling Invocation objects so I thought I'd test to
see
if it is actually better. With this test case, its about 4% faster to
pool
on JDK 1.3.1 Win2k.
With JDK 1.4.0 on Win2k, Non-pooling is actually 7% faster!
import java.util.*;
public class testpool
{
HashMap trans;
HashMap as;
HashMap pay;
public testpool()
{
trans = new HashMap();
as = new HashMap();
pay = new HashMap();
}
public void clear()
{
trans.clear();
as.clear();
pay.clear();
}
public void addStuff()
{
for (int i = 0; i 5; i++)
{
trans.put(new Integer(i), new Integer(i));
as.put(new Integer(i), new Integer(i));
pay.put(new Integer(i), new Integer(i));
}
}
public static LinkedList pool = new LinkedList();
public static void main(String[] args)
{
long start;
long end;
System.out.println(testing non pool);
start = System.currentTimeMillis();
for (int i = 0; i 100; i++)
{
testpool p = new testpool();
p.addStuff();
}
end = System.currentTimeMillis() - start;
System.out.println(time: + end);
System.out.println(testing pool);
start = System.currentTimeMillis();
for (int i = 0; i 100; i++)
{
testpool p = null;
if (pool.isEmpty()) p = new testpool();
else
{
synchronized(pool)
{
p = (testpool)pool.removeFirst();
}
}
if (p == null) p = new testpool();
p.addStuff();
p.clear();
synchronized(pool)
{
pool.add(p);
}
}
end = System.currentTimeMillis() - start;
System.out.println(time: + end);
}
}}
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] YAJI (Yet Another JBoss Invoker)
Hi, I am also playing with a new invoker. Well, not really new... It is actually the JRMP invoker code, with just a few changes to sent the Invocation over IIOP rather than JRMP. In the lack of a better name, I am calling it JavaIIOPInvoker. JavaIIOPInvoker is quite different from the plain IIOPInvoker. It is also much simpler. By way of comparison: - IIOPInvoker allows IIOP access to the actual interfaces of deployed beans. When a client calls create() on an EJBHome, an IIOP request with operation name create goes over the wire and is handled by the plain IIOPInvoker. - JavaIIOPInvoker allow IIOP acess to a single interface: Invoker, which essentially has a single operation, invoke(). When a client class create() on an EJBHome, an IIOP request with operation name invoke goes over the wire and is handled by the JavaIIOPInvoker. Info on the actual method to be invoked (create(), in this case) goes within the Invocation parameter to invoke(). Unlike IIOPInvoker, which uses an IORFactory, JavaIIOPInvoker works with the standard JBoss ProxyFactory. Whan a client gets a reference to an EJBHome or EJBObject, it really gets a serialized Java proxy, just like in the JRMP case. The only difference is that this proxy's delegate has a CORBA reference (IOR) to the JavaIIOPInvoker, instead of a RMI/JRMP reference to the JRMPInvoker. Everything else works (or should work) as in the JRMP case: interceptors, client container, transactions, etc. JavaIIOPInvoker is useless to non-Java clients (hence its name). I am interested in comparing it with the JRMPInvoker WRT performance. So far (a simple hello test) I got pretty much the same numbers... Of course, the performance may change with the ORB used. I am doing everything with JacORB. Should I commit this stuff? Right now I am not really sure if it will be useful or not. Cheers, Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Our IIOP port number
So far we have been using port 8683 for IIOP. We picked the well know port number assigned to IIOP (which is 683) and added 8000 just to get out of the system port range. However, 8683 is not an officially assigned user port for IIOP (there is no such a thing), but simply an unassigned port that we should not be using. The officially assigned ports are in http://www.iana.org/assignments/port-numbers So I have requested IANA a user port assignment for JBoss/IIOP. We got the following ports: jboss-iiop 3528/tcp JBoss IIOP jboss-iiop 3528/udp JBoss IIOP jboss-iiop-ssl 3529/tcp JBoss IIOP/SSL jboss-iiop-ssl 3529/udp JBoss IIOP/SSL I will change jacorb.properties in 3.0 and HEAD to switch from 8683 to 3528. As a consequence, there will be a change in the naming service IOR used in the testsuite (which is equivalent to corbaloc://1.2@localhost:8683/JBoss/Naming/root) and in all JBoss-generated IORs. (If you have an app that stores IORs of EJBHomes or EJBObjects, beware! You might want to edit jacorb.properties to retain the old port and avoid regenerating your IORs.) Cheers, Francisco --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] HEAD broken?
Did a fresh checkout, but the server refuses to run. A stack trace is included below. Switching JDK does not make a difference: tried Sun 1.3.1_03, Sun 1.4.0, and IBM 1.3.1 (all on Linux). Is anybody else seeing this? Cheers, Francisco -- 10:11:23,448 ERROR [MainDeployer] could not create deployment: file:/home/reverbel/co/jboss-all/build/output/jboss-3.1.0alpha/server/default/conf/jboss-service.xml java.lang.NoSuchFieldError: problem at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:190) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:131) at org.jboss.system.ServiceController.install(ServiceController.java:225) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.install(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:227) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:758) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:623) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:588) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:572) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy6.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:232) at org.jboss.Main.boot(Main.java:146) at org.jboss.Main$1.run(Main.java:379) at java.lang.Thread.run(Thread.java:479) 10:11:23,487 ERROR [Server] Failed to start --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shouldn't the ejb invoker binding be in thecontainer-configuration section
This is pretty much what we have in 3.1. Look at the jboss.xml file of the hellojrmpiiop test: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jbosstest/src/resources/hellojrmpiiop/META-INF/jboss.xml?rev=1.1content-type=text/vnd.viewcvs-markup Cheers, Francisco On Sun, 14 Jul 2002, Scott M Stark wrote: What I would like to see is something like this: jboss enterprise-beans session ejb-nameMySession/ejb-name configuration-nameStandard Stateless SessionBean/configuration-name client-configuration-names client-configuration-nameStateless Session/JRMP/client-configuration-name client-configuration-nameStateless Session/IIOP/client-configuration-name /client-configuration-names /session /enterprise-beans client-container-configurations client-container-configuration container-nameStateless Session/JRMP/container-name invoker-namejboss:service=invoker,type=jrmp/invoker-name client-interceptors home interceptororg.jboss.proxy.ejb.HomeInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /home bean interceptororg.jboss.proxy.ejb.EntityInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /bean /client-interceptors ... /client-container-configuration /client-container-configurations /jboss I have only glaced out the 3.1 parsing so maybe this is what we are doing there, but it certainly is not how 3.0 is handling invokers. Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Testsuite problems -- no all conf.
Great, we're back in business. The testsuite runs again. Thanks, Francisco On Sun, 9 Jun 2002, Scott M Stark wrote: I updated the build file with some changes that were missing for the multi-config build output. The all config is now populated correctly. - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Sunday, June 09, 2002 4:43 PM Subject: [JBoss-dev] Testsuite problems -- no all conf. I think the reason the automatic testsuite is failing is that there is no configuration for the all setup, just a lib directory. Also I think it might possibly make more sense to copy each jar to its (minimal) final location, then copy all of minimal/[lib deploy] to default, and all of default to all. Perhaps someone who has worked on this previously could take another look. thanks david jencks ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build not working on Linux?
Thanks for your reply, Jason. Eventually we will have everything listed... in fact we have a similar include for the javac task, so perhaps XDoclet needs to be fixed to not cache so much data at one (or whatever). Yes. Have you tried increasing the heap for the vm used to build? I would prefer that local fix to this global one. JAVA_OPTS=-X128m build/build.sh I have, but still got OutOfMemoryError. (Had to say -Xms128m -Xmx128m, though. The 1.3 VM doesn't recognize -X128m as an option. And with just -Xms128m it complains about incompatible initial and max heap sizes.) Best, Francisco ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build not working on Linux?
On Sun, 26 May 2002, Matthew Tippett wrote: Technically speaking the docset is not 'too big', it is simply causes too many native threads to be created for most 'default' Linux distributions. Run the sample program and you should with a Linux 2.4 system get around 220ish threads. The options without the change are as follows. o Use build.compiler=classic (which kicks the JVM into green threads which doesn't have a 'real' thread limit. Not a real option, as some VMs (the newer ones) don't support green threads. o Set ulimit -u to greater around 1024 Yes, this worked fine for me. Thanks! o Modify /etc/security/limits.conf and nprocs to something around 1024 In my system (Debian Woody) /etc/security/limits.conf is essentially empty (only has commented out example entries), so I guess this is the reason `ulimit -u 1024' worked for me without any change to limits.conf. So the 'fix' is a workaround. (Probably is the best solution for the moment, but it isn't a bug in the code, more so a configuration problem in the standard configuration of Linux distributions. Just thought people might be interested (I spent about 2 hours attempting to get my first CVS build running when I came across this problem :). This sounds like an argument for the fix/workaround/whatever. It shouldn't be this hard to build and run the CVS code! (Yesterday I had just a couple of hours for some JBoss hacking and also spent them on the xdoclet error...) Cheers, Francisco ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Build not working on Linux?
Help! I am running build/build.sh on HEAD and Branch_3_0 trees just checked out from CVS. On both trees build fails within xdoclet: java.lang.OutOfMemoryError: unable to create new native thread (Branch 3.0 error included below.) Both Sun and IBM JDKs are giving me the same error. My config is: Linux pong 2.4.10 #1 Sun Oct 14 23:31:01 BRST 2001 i686 unknown Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode) Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)) Is anybody else seeing this? Thanks, Francisco == == Executing 'most' in module 'server'... == _buildmagic:init: configure: init: generate-parsers: Target is already built - skipping (/home/reverbel/Branch_3_0/jboss-all/server/\ src/main/org/jboss/ejb/plugins/cmp/ejbql/JBossQLParser.jjt) Target is already built - skipping (/home/reverbel/Branch_3_0/jboss-all/server/\ src/main/org/jboss/ejb/plugins/cmp/ejbql/EJBQLParser.jjt) compile-bean-sources: sourcepath is deprecated. the preferred way to design sources is via nested fi\ leset Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:\ true [xdoclet] Running homeInterface/ [xdoclet] Running remoteInterface/ [xdoclet] Running session/ [xdoclet] Running deploymentDescriptor/ [xdoclet] Running jboss/ compile-mbean-sources: sourcepath is deprecated. the preferred way to design sources is via nested fi\ leset Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:\ true [xdoclet] Running mbeanInterface/ [xdoclet] java.lang.OutOfMemoryError: unable to create new native thread [xdoclet] at java.lang.Thread.start(Native Method) [xdoclet] at xjavadoc.XJavaDoc.scanAndPut(XJavaDoc.java:562) [xdoclet] at xjavadoc.XJavaDoc.getXClass(XJavaDoc.java:393) [xdoclet] at xjavadoc.ProxyClass.resolve(ProxyClass.java:584) [xdoclet] at xjavadoc.ProxyClass.doc(ProxyClass.java:483) [xdoclet] at xdoclet.DocletSupport.isDocletGenerated(DocletSupport.java:2\ 69) [xdoclet] at xdoclet.TemplateSubTask.matchesGenerationRules(TemplateSubTa\ sk.java:633) [xdoclet] at xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:57\ 6) [xdoclet] at xdoclet.TemplateSubTask.execute(TemplateSubTask.java:488) [xdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:54) [xdoclet] at xjavadoc.ant.XJavaDocMain.main(XJavaDocMain.java:94) Is anybody else seeing this? I am on Linux ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build not working on Linux?
Found the cause: a recent change on server/build.xml made xdoclet to be called on a fileset too big (name=**/*.java). I will revert the change. But it is strange that nobody else saw this... I have tried two Linux machines (a laptop with 128M and a box with 384M) with the same result: xdoclet barfed on the big fileset. Maybe there is something in my Linux environment that made me run out of memory before anybody else. Cheers, Francisco On Sat, 25 May 2002, Francisco Reverbel wrote: Help! I am running build/build.sh on HEAD and Branch_3_0 trees just checked out from CVS. On both trees build fails within xdoclet: java.lang.OutOfMemoryError: unable to create new native thread (Branch 3.0 error included below.) Both Sun and IBM JDKs are giving me the same error. My config is: Linux pong 2.4.10 #1 Sun Oct 14 23:31:01 BRST 2001 i686 unknown Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode) Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)) Is anybody else seeing this? Thanks, Francisco == == Executing 'most' in module 'server'... == _buildmagic:init: configure: init: generate-parsers: Target is already built - skipping (/home/reverbel/Branch_3_0/jboss-all/server/\ src/main/org/jboss/ejb/plugins/cmp/ejbql/JBossQLParser.jjt) Target is already built - skipping (/home/reverbel/Branch_3_0/jboss-all/server/\ src/main/org/jboss/ejb/plugins/cmp/ejbql/EJBQLParser.jjt) compile-bean-sources: sourcepath is deprecated. the preferred way to design sources is via nested fi\ leset Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:\ true [xdoclet] Running homeInterface/ [xdoclet] Running remoteInterface/ [xdoclet] Running session/ [xdoclet] Running deploymentDescriptor/ [xdoclet] Running jboss/ compile-mbean-sources: sourcepath is deprecated. the preferred way to design sources is via nested fi\ leset Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:\ true [xdoclet] Running mbeanInterface/ [xdoclet] java.lang.OutOfMemoryError: unable to create new native thread [xdoclet] at java.lang.Thread.start(Native Method) [xdoclet] at xjavadoc.XJavaDoc.scanAndPut(XJavaDoc.java:562) [xdoclet] at xjavadoc.XJavaDoc.getXClass(XJavaDoc.java:393) [xdoclet] at xjavadoc.ProxyClass.resolve(ProxyClass.java:584) [xdoclet] at xjavadoc.ProxyClass.doc(ProxyClass.java:483) [xdoclet] at xdoclet.DocletSupport.isDocletGenerated(DocletSupport.java:2\ 69) [xdoclet] at xdoclet.TemplateSubTask.matchesGenerationRules(TemplateSubTa\ sk.java:633) [xdoclet] at xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:57\ 6) [xdoclet] at xdoclet.TemplateSubTask.execute(TemplateSubTask.java:488) [xdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:54) [xdoclet] at xjavadoc.ant.XJavaDocMain.main(XJavaDocMain.java:94) Is anybody else seeing this? I am on Linux ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] NoSuchMethodError in MainDeployer
Did you buid JBoss with JDK 1.4 and attempted to start the server with IBM's 1.3 or 1.3.1 VM for Linux, by any chance? I had trouble in this case. It appears that a 1.4-generated server barfs with IBM's 1.3.x VMs for Linux. Do not ask me why... ;-( Best, Francisco On Tue, 21 May 2002, Dain Sundstrom wrote: I can't seem to get the server to start anymore. I did a fresh checkout and rebuild. When I start the server I get the following exception: 13:50:58,280 ERROR [Server] start failed org.jboss.deployment.DeploymentException: Could not create deployment: file:/hom e/dain/work/jboss/jboss-head/build/output/jboss-3.1.0alpha/server/default/conf/j boss-service.xml; - nested throwable: (java.lang.NoSuchMethodError) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:698) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:484) java.lang.NoSuchMethodError at org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.getLast Modified(URLDeploymentScanner.java:304) at org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.deploye d(URLDeploymentScanner.java:274) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen tScanner.java:375) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDe ploymentScanner.java:555) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS canner.java:434) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A bstractDeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 98) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl ler.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:341) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:686) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:484) -dain ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JRMP and IIOP invocations to the same container...
are now working in 3.1 (CVS HEAD). Marc: your vision is real!!! Even concurrent JRMP and IIOP invocations appear to be working fine. I have committed yet another version of the hello test (hellojrmpiiop) to demonstrate this. Here is a summary of the recent changes on the IIOP stuff in 3.1: - The EJB-specific IIOPContainerInvoker is gone. Its functionality is now split between a generic IIOPInvoker MBean and an EJB-specific IORFactory, which is the IIOP version of a ProxyFactory. - These two guys interact in the following way: the IORFactory registers CORBA servants with the IIOPInvoker, which returns to the IORFactory reference factories the IORFactory uses to create CORBA references. Two new interfaces are involved: ServantRegistry and ReferenceFactory, both implemented by objects provided/returned by the IIOPInvoker. - An IORFactory is associated to a given container. It creates two CORBA servants: an EjbHomeCorbaServant and an EjbObjectCorbaServant. Both are thin wrappers that forward invocations to the container, through the JBoss MBean server. - Other CORBA reference factories (which don't need to be EJB-specific) may also use the IIOPInvoker. As an example, the in-VM CORBA naming service in 3.1 has been modified to register its servants with the IIOPInvoker. A next step would be an IIOP Java proxy factory that talks to the IIOPinvoker. (Any volunteers?...) - The CORBA naming service has been taken off the CORBA ORB service and is now a separate MBean. - IIOP-specific container configurations are gone. Now you just specify the iiop invoker-proxy-binding. - The proxy-factory-config of an IORFactory takes the following sub-elements (see iiop proxy binding in standardjboss.xml): - web-class-loader: Moved from the container configuration. Must contain org.jboss.iiop.WebCL. - poa: May be shared (a single POA shared among all servants bound to a ServantRegistry) or per-servant (a separate POA is created for each servant bound to a ServantRegistry). The default value in the iiop invoker-proxy-binding in standardjboss.xml is per-servant. - register-ejbs-in-jnp-context: If true, EJBHome IORs are registered with the JBoss JNP naming service in addition to being registered with the CORBA naming service. If false EJBHome IORs are registered only with the CORBA naming service. The default value in the iiop invoker-proxy-binding in standardjboss.xml is true. - jnp-context: Only meaningful it the previous element is true. Specifies the JNP naming context EJBHome IORs will be bound to. If absent, EJB IORs will be bount to the root JNP naming context. The default value in the iiop invoker-proxy-binding in standardjboss.xml is iiop. To clarify the last two config elements: in the hellojrmpiiop test, the JRMP reference to the EJBHome is bound to helloworld/Hello in the JNP naming service. The EJBHome IOR is bound to helloworld/Hello in the CORBA naming service and to iiop/helloworld/Hello in the JNP naming service (because register-ejbs-in-jnp-context is true and jnp-context is iiop). Let me know what you think of this arrangement. Suggestions/ideas are very welcome. And please let me know of any problems. This stuff is built upon Bill's great work on multiple invokers. It is also a consequence of very enlightening discussions with Marc and Bill. Thanks, guys! Best, Francisco ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Talk on IIOP support in JBoss
For those in South America this coming week: on May 23 (4:30PM) I will be an invited speaker at the Objetos 6006 conference, in Sao Paulo, Brazil. This event is jointly organized by three Sao Paulo user groups -- the OO/UML user group, the Java user group, and the CORBA user group. More info (in Portuguese): http://www.objetos6006.com.br/palestras.htm The conference schedule is in http://www.objetos6006.com.br/palestras.htm Cheers, Francisco ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX RMI Adapter JNDI binding
On Sun, 12 May 2002, Jason Dillon wrote: Currently we are binding to jmx:hostname:rmi which is fine when you are working with the localhost, but will start to cause problems once used in a multi-host environment. ... So for a client on a remote host to correctly make use of the deployer.sh or any other simialr tool using the jmx adapter it will have to have knowledge of the servers local hostname (as returned by java.net.InetAddress.getLocalHost().getHostName()) and specify that value for --server, then specify -Djava.naming.provider.url=jnp://www.mydomain.com. This may also be an issue if you have a client running in the same host as the server, but on a VM from other vendor. When I run java.net.InetAddress.getLocalHost().getHostName() on a Sun VM, I get something like myhost.mydomain.com. When I do the same thing on an IBM VM for Linux, I get myhost. This appears to be the reason the whole testsuite fails if I use a Sun VM for the server and an IBM VM for the testsuite clients (or vice-versa). Regards, Francisco ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss built with JDK 1.4 doesn't run on IBM VMs?
Hello, I am running Debian Linux 3.0, kernel 2.4.10. Built JBoss 3.1 (CVS HEAD) with Sun JDK 1.4. The server barfs with IBM VMs 1.3 and 1.3.1. A stack trace is included below. The same 1.4-built server runs fine with Sun VMs 1.3.1_02, 1.3.1_03, and 1.4. Rebuilt the server from scratch, now with Sun JDK 1.3.1_03. The 1.3-built server runs fine on Sun and on IBM VMs. Does anybody else see this? Cheers, Francisco -- stack trace - 2002-05-11 22:02:43,286 INFO [org.jboss.deployment.scanner.URLDeploymentScanner] Starting 2002-05-11 22:02:43,300 ERROR [org.jboss.deployment.MainDeployer] could not start deployment: file:/home/reverbel/jboss-all/build/output/jboss-3.1.0alpha/server/default/conf/jboss-service.xml java.lang.AbstractMethodError: org/jboss/deployment/scanner/AbstractDeploymentScanner.scan at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:198) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:342) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:692) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:527) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:490) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:498) 2002-05-11 22:02:43,329 ERROR [org.jboss.deployment.MainDeployer] Couldn't deploy URL file:/home/reverbel/jboss-all/build/output/jboss-3.1.0alpha/server/default/conf/jboss-service.xml ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] testsuite in HEAD does not build
Hi, The error I got was caused by what seemed to be a typo in testsuite/build.xml. With this typo the testsuite build was failing on both jdk1.3 and jdk1.4. After I've fixed it, I still got a compilation error on jdk1.4 (at a later point), but build succeeded on jdk1.3. I was in a hurry, so didn´t look into the compilation problem and went on to run the tests I have managed to build with jdk1.3... I guess you didn't get the same error I got because you updated your tree after I commited my fix. Thanks for fixing the compilation problem with jdk1.4! Francisco On Sun, 5 May 2002, danch wrote: Didn't get that error there, but I did get an compile problem in the newbank stuff related to the fact that 1.4 defines a throwable 'cause' property in Exception and newbank has an exception class with an Exception cause properly. I've fixed that and will check in as soon as I confirm that it will compile under 1.3 (i don't see why it wouldn't, but...) I did just do a clean checkout because the 'most' target would build for me and I felt like it was Just Time to Do That. maybe you have an old xdoclet or an version mismatch between ant and xdoclet? -danch Francisco Reverbel wrote: Is anybody else getting this? I am using jdk1.4 on linux. Francisco - ... [xdoclet] Running deploymentDescriptor/ [xdoclet] Running jboss/ [execmodules] Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:true [xdoclet] Exception in thread main java.lang.NoClassDefFoundError: xdoclet/XDocletMain [execmodules] /home/reverbel/jboss-all/testsuite/build.xml:599: Java returned: 1[execmodules]at org.apache.tools.ant.taskdefs.Java.execute(Java.java:90) [execmodules] at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:175) [execmodules] at xdoclet.DocletTask.execute(DocletTask.java:298) [execmodules] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104) [execmodules] at org.apache.tools.ant.Task.perform(Task.java:217) ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] testsuite in HEAD does not build
Is anybody else getting this? I am using jdk1.4 on linux. Francisco - ... [xdoclet] Running deploymentDescriptor/ [xdoclet] Running jboss/ [execmodules] Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:true [xdoclet] Exception in thread main java.lang.NoClassDefFoundError: xdoclet/XDocletMain [execmodules] /home/reverbel/jboss-all/testsuite/build.xml:599: Java returned: 1[execmodules]at org.apache.tools.ant.taskdefs.Java.execute(Java.java:90) [execmodules] at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:175) [execmodules] at xdoclet.DocletTask.execute(DocletTask.java:298) [execmodules] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104) [execmodules] at org.apache.tools.ant.Task.perform(Task.java:217) [execmodules] at org.apache.tools.ant.Target.execute(Target.java:164) [execmodules] at org.apache.tools.ant.Target.performTasks(Target.java:182) [execmodules] at org.apache.tools.ant.Project.executeTarget(Project.java:601) [execmodules] at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) [execmodules] at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:269) [execmodules] at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:184) [execmodules] at org.apache.tools.ant.Task.perform(Task.java:217) [execmodules] at org.apache.tools.ant.Target.execute(Target.java:164) [execmodules] at org.apache.tools.ant.Target.performTasks(Target.java:182) [execmodules] at org.apache.tools.ant.Project.executeTarget(Project.java:601) [execmodules] at org.apache.tools.ant.Project.executeTargets(Project.java:560)[execmodules] at org.apache.tools.ant.Main.runBuild(Main.java:454) [execmodules] at org.apache.tools.ant.Main.start(Main.java:153) [execmodules] at org.apache.tools.ant.Main.main(Main.java:176) BUILD FAILED /home/reverbel/jboss-all/testsuite/build.xml:599: Java returned: 1 Total time: 34 seconds ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Clustering Hanging and JVM Bind
On Wed, 1 May 2002, Theo Harper wrote: Thanks for the help regarding the IIOP hang, after changing the port to 8683 JBoss starts up okay. Will Branch_3_0_0 be updated with this fix? The default IIOP port is already 8683 in HEAD, Branch_3_0_0, and 3.0.0RC2. Francisco ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] IIOP port conflict on Windows XP
As Adrian pointed out some time ago, the IIOP port in the default config in HEAD and branch 3.0 (port 5000) conflicts with a Windows XP service (SSDP Discovery Service, used for Universal Plug and Play). I considered changing the default config and moving IIOP to the port officially reserved for IIOP. but this is not a good option. The official IIOP port (683) is in the well-known port range (0--1023), normally unavailable to processes with no special privileges. So I requested IANA a port assignment (in the registered port range, which is from 1024 to 49151) for JBoss. In a couple of weekes we should have our own registered port for JBoss/IIOP. Meanwhile, I do not know what to do with the IIOP port. The current value is causing problems for Windows XP users. Changing it to another stolen value is also likely to cause problems... Francisco
Re: [JBoss-dev] IIOP port conflict on Windows XP
Will do it. Just checked at www.iana.org and 8683 is unassigned, so it should be better than our current port. Thanks, Francisco On Tue, 30 Apr 2002, Jason Dillon wrote: Why not change it to 8683 by default then? --jason Francisco Reverbel wrote: As Adrian pointed out some time ago, the IIOP port in the default config in HEAD and branch 3.0 (port 5000) conflicts with a Windows XP service (SSDP Discovery Service, used for Universal Plug and Play). I considered changing the default config and moving IIOP to the port officially reserved for IIOP. but this is not a good option. The official IIOP port (683) is in the well-known port range (0--1023), normally unavailable to processes with no special privileges. So I requested IANA a port assignment (in the registered port range, which is from 1024 to 49151) for JBoss. In a couple of weekes we should have our own registered port for JBoss/IIOP. Meanwhile, I do not know what to do with the IIOP port. The current value is causing problems for Windows XP users. Changing it to another stolen value is also likely to cause problems... Francisco
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On Wed, 24 Apr 2002, Anatoly Akkerman wrote: It is a big and complex beast. I remember digging through it when I found some bugs, shrug ... It implements all the CORBA JTA stuff for distributed TXs. I just wrote a hack to propagate the transaction context together with JBoss MethodInvocation, instead of CORBA ORB -- the way Tyrex would do it. Do you reckon how difficult it would be to use Tyrex together with JBoss/IIOP and do transaction propagation the CORBA way? Best, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
This message jacob.properties not found is just a warning and can be ignored. I am about to commit some changes the will make it go away. Francisco On Tue, 23 Apr 2002, marc fleury wrote: he... did rm on the old stuff then a CLEAN CO then build (builds fine btw) then start and I get an error from IIOP. what gives? something about jacob.properties not being found Am I alone in seeing this? I want to fix the CL stuff and will try right now * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13812 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
On Tue, 23 Apr 2002, Jason Dillon wrote: Fransico, put in a dummy jacob.properties in default/conf when IIOP builds to avoid this mess please. This doesn't work, probably because JacORB is not using the context classloader to load its resources. Wait a moment, I will commit a simple change that will make this message go away. Later on I'll look into changing JacORB so that it loads resources with the TCL. Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] IIOP barfs on linux
You may need to upgrade your JDK to build the IIOP stuff, due to an rmic bug in some older JDK versions. You should not need to upgrade you JDK to run IIOP. If it is already built then it should run. (With a jacorb.properties not found warning, which will go away in a few minutes...) Are you seeing something different, Marc? Francisco On Tue, 23 Apr 2002, marc fleury wrote: righto... I still recommend we disable IIOP by default and just turn it on with a BIG warning in the service.xml file THAT YOU SHOULD BE USING JDK1.3.1 or JDK1.4, can we keep a service.xml and sort of comment out everything? that would be useful. Francisco, can you take care of that? marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Tuesday, April 23, 2002 3:29 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] IIOP barfs on linux | | |Are you using the newest version of 1.3.1 from SUN? If not, you need to |upgrade. If you are using 1.4, just ignore me. | |Also I thought the jacob.properties was just a warning. | |-dain | |marc fleury wrote: | | he... | | did rm on the old stuff | then a CLEAN CO | then build (builds fine btw) | then start and I get an error from IIOP. | | what gives? | | something about jacob.properties not being found | | Am I alone in seeing this? | | | I want to fix the CL stuff and will try right now | * * * | | View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13812 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IIOP barfs on linux
Francisco the error that I am seeing my VM is java version 1.3.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010502 (JIT enabled: jitc) This is a known problem in the IBM VM. Just commited some changes that deal with it. The changes implement the workaround I discussed with Jason. Could you please update your CVS tree and try again? (The warning message and all spurious JacORB output should also vanish.) Francisco * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13812 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: Sill a problem with IIOP startup...
Sorry for the trouble. Port 5000 was just a random (and poor) choice I have made when implementing the IIOP stuff. I will change the default config and move IIOP to the port officially reserved for IIOP, whatever such port is (do not have the OMG docs at hand right now). As for the warning complaining that no jacorb properties file was found, it can be ignored. Maybe we should have a dummy jacorb.properties file in run.jar just to avoid this warning... Best, Francisco On Sun, 21 Apr 2002, Adrian Brock wrote: Hi Jason, There is a service on Windows XP that sits on port 5000 (same one used by iiop). It is called SSDP Discovery Service, it used for Universal Plug and Play. I fixed the problem by disabling both the SSDP service and the Universal Plug and Play Device Host service, since I don't need them. Regards, Adrian I am still getting errors like this from a default build: snip 21:16:01,826 INFO [MainDeployer] Successfully completed deployment of package: file:/C:/home/jason/workspace/jboss/jboss-all/build/ou put/jboss-3.1.0alpha/server/default/deploy/jbossmq-des inations-service.xml 21:16:01,826 INFO [MainDeployer] Starting deployment of package: file:/C:/home/jason/workspace/jboss/jboss-all/build/ou put/jboss-3.1.0alpha/server/default/deploy/iiop-servic .xml 21:16:02,116 INFO [CorbaORBService] Creating 21:16:02,116 INFO [CorbaORBService] Created 21:16:02,116 INFO [CorbaORBService] Starting 21:16:02,227 ERROR [STDERR] ## ## 21:16:02,227 ERROR [STDERR] WARNING: no properties file found! This warning can be ignored for applets. A file file called jacorb.properties or .jacorb_properties should be present in the classpath, the home directory (C:\Documents and Settings\jason), the current directory (.) or in Javas lib directory (c:\java\jdk1.3.1_02\jre) 21:16:02,227 ERROR [STDERR] ## ## 21:16:02,277 INFO [STDOUT] JacORB V 1.4 beta 4, www.jacorb.org 21:16:02,277 INFO [STDOUT] (C) Gerald Brose, FU Berlin, March 2002 21:16:02,537 INFO [STDOUT] [ POA RootPOA - ready ] 21:16:02,567 ERROR [STDERR] [ Listener: Couldn't initialize. Illegal address configuration? ] 21:16:02,567 INFO [Server] undeploying all packages 21:16:02,567 INFO [MainDeployer] Undeploying file:/C:/home/jason/workspace/jboss/jboss-all/build/ou put/jboss-3.1.0alpha/server/default/deploy/iiop-servic .xml 21:16:02,567 INFO [CorbaORBService] Destroying 21:16:02,567 INFO [CorbaORBService] Destroyed /snip And then it appears that the startup sequence is hung... I never see the final started message. WTF? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13521 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: Sill a problem with IIOP startup...
On Sun, 21 Apr 2002, Jason Dillon wrote: I really don't like that we have to put stuff into run.jar to solve IIOP/JacORB specific problems. Can we get around this? Or is this just to make it work in IBM? A jacorb.properties in run.jar would just avoid this warning: WARNING: no properties file found! This warning can be ignored for applets. A file file called jacorb.properties or .jacorb_properties should be present in the classpath, the home directory (C:\Documents and Settings\jason), the current directory (.) or in Javas lib directory (c:\java\jdk1.3.1_02\jre) The warning may be ignored, so we don't really need to do anything here. The user can get rid of the warning by putting a jacorb.properties file in any of the places indicated. Just thought that a dummy properties file in run.jar would make things look nicer. The IBM problem cannot be solved with a jacorb.properties file in run.jar. To solve it we need one more class file in run.jar. I have implemented (but did not commit) this. Works perfectly, but run.jar grows from 24264 bytes to 27211 bytes. A lame workaround (which does not work for netboot) would be to add jacorb.jar to the system classpath. Best, Francisco --jason Quoting Francisco Reverbel [EMAIL PROTECTED]: Sorry for the trouble. Port 5000 was just a random (and poor) choice I have made when implementing the IIOP stuff. I will change the default config and move IIOP to the port officially reserved for IIOP, whatever such port is (do not have the OMG docs at hand right now). As for the warning complaining that no jacorb properties file was found, it can be ignored. Maybe we should have a dummy jacorb.properties file in run.jar just to avoid this warning... Best, Francisco On Sun, 21 Apr 2002, Adrian Brock wrote: Hi Jason, There is a service on Windows XP that sits on port 5000 (same one used by iiop). It is called SSDP Discovery Service, it used for Universal Plug and Play. I fixed the problem by disabling both the SSDP service and the Universal Plug and Play Device Host service, since I don't need them. Regards, Adrian I am still getting errors like this from a default build: snip 21:16:01,826 INFO [MainDeployer] Successfully completed deployment of package: file:/C:/home/jason/workspace/jboss/jboss-all/build/ou put/jboss-3.1.0alpha/server/default/deploy/jbossmq-des inations-service.xml 21:16:01,826 INFO [MainDeployer] Starting deployment of package: file:/C:/home/jason/workspace/jboss/jboss-all/build/ou put/jboss-3.1.0alpha/server/default/deploy/iiop-servic .xml 21:16:02,116 INFO [CorbaORBService] Creating 21:16:02,116 INFO [CorbaORBService] Created 21:16:02,116 INFO [CorbaORBService] Starting 21:16:02,227 ERROR [STDERR] ## ## 21:16:02,227 ERROR [STDERR] WARNING: no properties file found! This warning can be ignored for applets. A file file called jacorb.properties or .jacorb_properties should be present in the classpath, the home directory (C:\Documents and Settings\jason), the current directory (.) or in Javas lib directory (c:\java\jdk1.3.1_02\jre) 21:16:02,227 ERROR [STDERR] ## ## 21:16:02,277 INFO [STDOUT] JacORB V 1.4 beta 4, www.jacorb.org 21:16:02,277 INFO [STDOUT] (C) Gerald Brose, FU Berlin, March 2002 21:16:02,537 INFO [STDOUT] [ POA RootPOA - ready ] 21:16:02,567 ERROR [STDERR] [ Listener: Couldn't initialize. Illegal address configuration? ] 21:16:02,567 INFO [Server] undeploying all packages 21:16:02,567 INFO [MainDeployer] Undeploying file:/C:/home/jason/workspace/jboss/jboss-all/build/ou put/jboss-3.1.0alpha/server/default/deploy/iiop-servic .xml 21:16:02,567 INFO [CorbaORBService] Destroying 21:16:02,567 INFO [CorbaORBService] Destroyed /snip And then it appears that the startup sequence is hung... I never see the final started message. WTF? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13521 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest build.xml
User: reverbel
Date: 02/04/20 12:31:05
Modified:.build.xml
Log:
- IIOP tests excluded from tests-standard-stress.
- Created target tests-iiop-stress.
- Targets tests and tests-stress now depend on tests-iiop-stress.
Revision ChangesPath
1.110 +56 -3 jbosstest/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosstest/build.xml,v
retrieving revision 1.109
retrieving revision 1.110
diff -u -r1.109 -r1.110
--- build.xml 18 Apr 2002 23:21:57 - 1.109
+++ build.xml 20 Apr 2002 19:31:05 - 1.110
@@ -13,7 +13,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.109 2002/04/18 23:21:57 starksm Exp $ --
+!-- $Id: build.xml,v 1.110 2002/04/20 19:31:05 reverbel Exp $ --
project default=main name=JBoss/Testsuite
@@ -2303,6 +2303,7 @@
tests-client-unit,
tests-security-basic-unit,
tests-standard-stress,
+ tests-iiop-stress,
tests-client-stress,
tests-security-basic-stress,
tests-jsr77-unit,
@@ -2328,7 +2329,8 @@
target name=tests-stress description=Execute all stress tests.
depends=init,
- tests-standard-stress,
+ tests-standard-stress,
+ tests-iiop-stress,
tests-client-stress,
tests-security-basic-stress,
tests-jbossmx-performance,
@@ -2440,12 +2442,13 @@
fileset dir=${build.classes}
include name=**/*StressTestCase.class/
- !-- do not include the perf or security tests --
+ !-- do not include the perf, security, or iiop tests --
!--mq test seems to break things--
!--exclude name=**/JBossMQPerfStressTestCase.class/--
exclude name=**/test/perf/test/SecurePerfStressTestCase.class/
exclude name=**/test/security/test/*/
exclude name=**/test/securitymgr/test/*/
+ exclude name=**/test/*iiop/test/*/
/fileset
/batchtest
/junit
@@ -2964,6 +2967,56 @@
include name=**/jbossmx/compliance/**/*TestCase.class/
!-- Ignore the abstract class --
exclude name=org/jboss/test/jbossmx/compliance/TestCase.class/
+/fileset
+ /batchtest
+/junit
+ /target
+
+ !--
+ | IIOP test cases that should run successfully
+ --
+
+ target name=tests-iiop-stress depends=maybejars
+mkdir dir=${build.reports}/
+mkdir dir=${build.testlog}/
+junit dir=${module.output}
+ printsummary=${junit.printsummary}
+ haltonerror=${junit.haltonerror}
+ haltonfailure=${junit.haltonfailure}
+ fork=${junit.fork}
+ timeout=${junit.timeout}
+ jvm=${junit.jvm}
+
+ jvmarg value=${junit.jvm.options}/
+ jvmarg value=-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB/
+ jvmarg
value=-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton/
+ jvmarg value=-Djava.security.manager/
+ sysproperty key=java.security.policy
+value=${build.resources}/security/tst.policy/
+ sysproperty key=jbosstest.deploy.dir file=${build.lib}/
+ sysproperty key=build.testlog value=${build.testlog}/
+ sysproperty key=log4j.configuration
value=file:${build.resources}/log4j.xml/
+ sysproperty key=jbosstest.threadcount value=${jbosstest.threadcount}/
+ sysproperty key=jbosstest.iterationcount
value=${jbosstest.iterationcount}/
+ sysproperty key=jbosstest.beancount value=${jbosstest.beancount}/
+
+ classpath
+pathelement location=${build.classes}/
+pathelement location=${build.resources}/
+path refid=tests.classpath/
+path refid=jboss.iiop.classpath/
+ /classpath
+
+ formatter classname=org.jboss.ant.taskdefs.XMLJUnitResultFormatter
+ extension=.xml usefile=${junit.formatter.usefile}/
+
+ batchtest todir=${build.reports}
+ haltonerror=${junit.batchtest.haltonerror}
+ haltonfailure=${junit.batchtest.haltonfailure}
+ fork=${junit.batchtest.fork}
+
+fileset dir=${build.classes}
+ include name=**/test/*iiop/test/*StressTestCase.class/
/fileset
/batchtest
/junit
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/iiop WebCL.java
User: reverbel Date: 02/04/19 05:46:28 Modified:iiop/src/main/org/jboss/iiop Tag: Branch_3_0 WebCL.java Log: Change merged from HEAD: use UnifiedClassLoader from org.jboss.mx.loading. Revision ChangesPath No revision No revision 1.3.2.1 +2 -2 contrib/iiop/src/main/org/jboss/iiop/WebCL.java Index: WebCL.java === RCS file: /cvsroot/jboss/contrib/iiop/src/main/org/jboss/iiop/WebCL.java,v retrieving revision 1.3 retrieving revision 1.3.2.1 diff -u -r1.3 -r1.3.2.1 --- WebCL.java12 Apr 2002 20:08:28 - 1.3 +++ WebCL.java19 Apr 2002 12:46:26 - 1.3.2.1 @@ -8,7 +8,7 @@ import org.jboss.logging.Logger; import org.jboss.proxy.compiler.IIOPStubCompiler; -import org.jboss.system.UnifiedClassLoader; +import org.jboss.mx.loading.UnifiedClassLoader; import org.jboss.web.WebClassLoader; /** ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/etc iiop-service.xml
User: reverbel Date: 02/04/19 05:58:44 Added: iiop/src/etc Tag: Branch_3_0 iiop-service.xml Log: Merged from HEAD: IIOP MBean moved to a separate service. Revision ChangesPath No revision No revision 1.1.2.1 +0 -0 contrib/iiop/src/etc/iiop-service.xml Index: iiop-service.xml === RCS file: /cvsroot/jboss/contrib/iiop/src/etc/iiop-service.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- iiop-service.xml 17 Apr 2002 13:34:49 - 1.1 +++ iiop-service.xml 19 Apr 2002 12:58:41 - 1.1.2.1 @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=UTF-8? !DOCTYPE server -!-- $Id: iiop-service.xml,v 1.1 2002/04/17 13:34:49 reverbel Exp $ -- +!-- $Id: iiop-service.xml,v 1.1.2.1 2002/04/19 12:58:41 reverbel Exp $ -- !-- = -- !-- -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/iiop CorbaORBService.java
User: reverbel
Date: 02/04/19 05:52:40
Modified:iiop/src/main/org/jboss/iiop Tag: Branch_3_0
CorbaORBService.java
Log:
Merged changes from HEAD:
- CorbaORBService now sets the system properties org.omg.CORBA.ORBClass and
org.omg.CORBA.ORBSingletonClass. Just passing these properties to the
first ORB.init() call was not enough, as this doesn't affect subsequent
(and parameterless) ORB.init() calls performed by stub code to obtain
references to the ORB singleton instance.
- If verbosity is zero then do not let JacORB send its version to stdout.
Revision ChangesPath
No revision
No revision
1.11.2.1 +10 -4 contrib/iiop/src/main/org/jboss/iiop/CorbaORBService.java
Index: CorbaORBService.java
===
RCS file: /cvsroot/jboss/contrib/iiop/src/main/org/jboss/iiop/CorbaORBService.java,v
retrieving revision 1.11
retrieving revision 1.11.2.1
diff -u -r1.11 -r1.11.2.1
--- CorbaORBService.java 14 Apr 2002 19:14:51 - 1.11
+++ CorbaORBService.java 19 Apr 2002 12:52:40 - 1.11.2.1
@@ -99,10 +99,16 @@
{
// Initialize the ORB
Properties props = new Properties();
- if (orbClass != null)
+ Properties systemProps = System.getProperties();
+ if (orbClass != null) {
props.put(org.omg.CORBA.ORBClass, orbClass);
- if (orbSingletonClass != null)
+ systemProps.put(org.omg.CORBA.ORBClass, orbClass);
+ }
+ if (orbSingletonClass != null) {
props.put(org.omg.CORBA.ORBSingletonClass, orbSingletonClass);
+ systemProps.put(org.omg.CORBA.ORBSingletonClass, orbSingletonClass);
+ }
+ System.setProperties(systemProps);
if (iiopPort != 0)
props.put(OAPort, Integer.toString(iiopPort));
if (portableInterceptorInitializerClass != null)
@@ -114,7 +120,7 @@
props.put(org.omg.PortableInterceptor.ORBInitializerClass.standard_init,
org.jacorb.orb.standardInterceptors.IORInterceptorInitializer);
props.put(jacorb.verbosity, Integer.toString(verbosity));
- props.put(jacorb.orb.print_version, on);
+ props.put(jacorb.orb.print_version, ((verbosity == 0) ? off : on));
orb = ORB.init(new String[0], props);
bind(ORB_NAME, org.omg.CORBA.ORB);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: thirdparty/jacorb/jacorb/lib README jacorb.jar
User: reverbel Date: 02/04/19 06:05:15 Modified:jacorb/jacorb/lib Tag: Branch_3_0 README jacorb.jar Log: Change merged from HEAD: Patched jacorb.jar to be compatible with org.omg.* stubs in JDK 1.4. Before this change we needed the Xbootclasspath switch to avoid loading org.omg.CosNaming._NamingContextExtStub from rt.jar. Revision ChangesPath No revision No revision 1.4.2.1 +17 -10thirdparty/jacorb/jacorb/lib/README Index: README === RCS file: /cvsroot/jboss/thirdparty/jacorb/jacorb/lib/README,v retrieving revision 1.4 retrieving revision 1.4.2.1 diff -u -r1.4 -r1.4.2.1 --- README4 Apr 2002 18:54:36 - 1.4 +++ README19 Apr 2002 13:05:09 - 1.4.2.1 @@ -1,9 +1,7 @@ The jacorb.jar file in this directory was generated from JacORB 1.4 beta 4, available at http://www.jacorb.org, by -applying the patch below. These changes were already merged -into the CVS HEAD version of JacORB and will be in the next -official release of JacORB. +applying the patch below. Kudos to the JacORB team, for this great open-source ORB. @@ -18,7 +16,7 @@ -- --- JacORB1_4_beta4/src/org/jacorb/orb/CDRInputStream.java Tue Mar 19 06:25:18 2002 -+++ JacORB/src/org/jacorb/orb/CDRInputStream.javaTue Apr 2 18:03:25 2002 JacORB/src/org/jacorb/orb/CDRInputStream.javaTue Apr 16 18:50:51 2002 @@ -34,7 +34,7 @@ * Read CDR encoded data * @@ -28,6 +26,15 @@ */ public class CDRInputStream +@@ -558,7 +558,7 @@ + org.jacorb.util.ValueHandler + .portableRemoteObject_narrow(read_Object(), clz); + else +-throw new org.omg.CORBA.NO_IMPLEMENT(); ++return read_Object(); + } + + public final byte read_octet () @@ -784,9 +784,15 @@ name = read_string(); // Debug.output(4, TC Union has name + 1.5.2.1 +387 -419 thirdparty/jacorb/jacorb/lib/jacorb.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss-service.xml
User: reverbel Date: 02/04/19 06:10:04 Modified:src/etc/conf/default Tag: Branch_3_0 jboss-service.xml Log: Merged change from HEAD: IIOP MBean moved to a separate service. Revision ChangesPath No revision No revision 1.44.2.1 +1 -16 jboss/src/etc/conf/default/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss-service.xml,v retrieving revision 1.44 retrieving revision 1.44.2.1 diff -u -r1.44 -r1.44.2.1 --- jboss-service.xml 14 Apr 2002 19:42:56 - 1.44 +++ jboss-service.xml 19 Apr 2002 13:10:03 - 1.44.2.1 @@ -108,21 +108,6 @@ !-- -- - !-- RMI/IIOP -- - !-- -- - !-- Uncomment to use the iiop module with JacORB - mbean code=org.jboss.iiop.CorbaORBService - name=jboss:service=CorbaORB -attribute name=ORBClassorg.jacorb.orb.ORB/attribute -attribute name=ORBSingletonClassorg.jacorb.orb.ORBSingleton/attribute -attribute name=IIOPServerNameJBoss/attribute -attribute name=IIOPPort5000/attribute -attribute name=PortableInterceptorInitializerClassorg.jboss.ejb.plugins.iiop.server.CodebaseInterceptorInitializer/attribute -attribute name=Verbosity1/attribute - /mbean - -- - - !-- -- !-- The deployers... -- !-- -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: reverbel
Date: 02/04/19 06:24:58
Modified:jbossTag: Branch_3_0 build.xml
Log:
Merged change from HEAD: copy iiop-service.xml to deploy dir.
Revision ChangesPath
No revision
No revision
1.117.2.2 +10 -1 build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/build/jboss/build.xml,v
retrieving revision 1.117.2.1
retrieving revision 1.117.2.2
diff -u -r1.117.2.1 -r1.117.2.2
--- build.xml 15 Apr 2002 09:36:40 - 1.117.2.1
+++ build.xml 19 Apr 2002 13:24:57 - 1.117.2.2
@@ -12,7 +12,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.117.2.1 2002/04/15 09:36:40 starksm Exp $ --
+!-- $Id: build.xml,v 1.117.2.2 2002/04/19 13:24:57 reverbel Exp $ --
project default=main name=JBoss/Build
@@ -1290,6 +1290,15 @@
include name=jacorb.jar/
/fileset
/copy
+
+!-- Copy deployable service file --
+mkdir dir=${install.server}/default/deploy/
+copy todir=${install.server}/default/deploy filtering=no
+ fileset dir=${_module.output}/etc
+ include name=iiop-service.xml/
+ /fileset
+/copy
+
/target
target name=_module-iiop-all depends=_module-iiop-most
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RC1 release branch occuring at 00:00
Hi Jason, Just noticed that the iiop stuff is not in the default build of Branch_3_0. Could you change this? Cheers, Francisco On Fri, 19 Apr 2002, Vesco Claudio wrote: OK, Claudio PS: I can do it now... :-) -Original Message- From: Francisco Reverbel [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 3:36 PM To: Vesco Claudio Cc: David Jencks; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject:RE: [JBoss-dev] RC1 release branch occuring at 00:00 On Wed, 17 Apr 2002, Vesco Claudio wrote: To Francisco, can you keep in synch HEAD with and RC1? I have merged my changes into Branch_3_0. Did the same with your fix to build/build.xml. Thanks to David and Dain for the CVS tips! Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] IIOP testcases
I want to make iiop tests run sucessfully at lubega. They must be removed from tests-standard-stress and placed in a new target, tests-iiop-stress. (Claudio: you did this already, right?) Then I guess we should make the tests-stress target depend on tests-iiop-stress. Is this right? I don't know what the lubega scripts do... Do they use the tests-stress target? Best, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
