RE: [JBoss-dev] cvs lock waiting
thanx -Original Message- From: Scott M Stark [SMTP:[EMAIL PROTECTED] Sent: Monday, June 07, 2004 6:58 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] cvs lock waiting Its been cleared. Scott Stark Chief Technology Officer JBoss Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vesco Claudio Sent: Monday, June 07, 2004 1:25 AM To: Jboss Dev (Posta elettronica) Subject: [JBoss-dev] cvs lock waiting Hi alls! There is a lock on cvs :-( cvs update: [06:43:00] waiting for jboss-build's lock in /cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/loading/util ... cvs update: [08:22:35] waiting for jboss-build's lock in /cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/loading/util -- -- PREVINET S.p.A. [EMAIL PROTECTED] -- Via Ferretto 1 ph x39-041-5907110 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] cvs lock waiting
Hi alls! There is a lock on cvs :-( cvs update: [06:43:00] waiting for jboss-build's lock in /cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/loading/util ... cvs update: [08:22:35] waiting for jboss-build's lock in /cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/loading/util -- -- PREVINET S.p.A. [EMAIL PROTECTED] -- Via Ferretto 1 ph x39-041-5907110 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004
Hi alls! I am working on org.jboss.test.jmx.test.EarDeploymentUnitTestCase: the test is not falling but the current implementation on EjbModule can give ClassLoader leak (WebClassLoader does not removed). I am also working to minimize the ClassLoaders leak, but this is another story. I try to explain this in another email. I have little patches on security and EJBSpecUnitTestCase: the security Provider must no be removed if it is not added. I'll commit shortly these patches. This is the report which I have when I run the testsuite in WindowsNT j2sdk 1.4.2_03 (single jboss, no cluster). I try to understand why I some errors that I don't have in linux. Claudio -- DETAILS OF ERRORS Suite: org.jboss.test.cache.test.replicated.AsyncUnitTestCase Test:testStateTransfer Type:failure Exception: junit.framework.AssertionFailedError Message: expected:2 but was:3 - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNoTx_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.exception.EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNoTx_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: org.jboss.test.jca.test.BaseConnectionManagerStressTestCase Test:testShortBlockingAggressiveRemoval Type:failure Exception: junit.framework.AssertionFailedError Message: Wrong number of connections counted: 2 - Suite: org.jboss.test.jmx.test.DeployServiceUnitTestCase Test:testSpaceInClasspath Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/D:/java/repositories/jboss/jboss-3.2-clean/testsuite/output/lib/archiv estest-service.xml; - nested throwable: (org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.test.jmx.mbean.TestDeployer; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.test.jmx.mbean.TestDeployer)) - Suite: org.jboss.test.management.test.JSR77SpecUnitTestCase Test:testNotificationDeliver Type:failure Exception: junit.framework.AssertionFailedError Message: Not enough notifications received: 0 - Suite: org.jboss.test.management.test.JSR77SpecUnitTestCase Test:testNavigation Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - Suite: org.jboss.test.naming.test.SecurityUnitTestCase Test:testSecureHttpInvoker Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: org.jboss.test.naming.test.SimpleUnitTestCase Test:testNameChanges Type:failure Exception: junit.framework.AssertionFailedError Message: name.equals(copy), name=jmx - Suite: org.jboss.test.naming.test.SimpleUnitTestCase Test:testHaParitionName Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Suite: org.jboss.test.naming.test.SimpleUnitTestCase Test:testDiscoveryPort
RE: [JBoss-dev] 4.0 Roadmap
I try to explain with examples :-) JAAS Authorization currently in jboss we have a AllPermission grant :-( I propose, for ejbs: jboss enterprise-beans session ejb-nameSampleEJB/ejb-name jndi-nameSampleJEB/jndi-name security-configuration authorization type=merge-with-parent principal name=role1 code=org.jboss.security.RolePrincipal/ permission code=org.jboss.mx.security.MBeanServerPermission name=invoke/ !-- this is a ejb spec violations, see ejb 2.1 pag 553, I must grant this explicitly -- permission code=java.io.FilePermission name=/home/ejb-app/tmp actions=read,write/ /authorization /security-configuration /session /enterprise-beans security-configuration authorization type=override principal name=role2 code=org.jboss.security.RolePrincipal/ permission code=org.jboss.mx.security.MBeanServerPermission name=get-attribute/ /authorization /security-configuration /jboss or for a sar: server mbean code=com.foo.service.Authorized name=com.foo:name=authorized security-configuration authorization type=override permission code=java.io.FilePermission name=/tmp actions=write/ /authorization /security-configuration /mbean /server we must have a similar configuration for connector (spec requirement) we can have a similar configuration form client app JAAS Authentication (this part can be simulated with the existing architecture in jboss, I propose a semplification and being able to associate the security domain to ejb and not to the application server and so on) currently in jboss.xml we have: jboss container-configurations container-configuration extends=Standard Stateless SessionBean container-nameDomain Stateless SessionBean/container-name security-domainjava:/jaas/security-domain/security-domain /container-configuration /container-configurations /jboss this make a LinkRef from java:comp/env/security/* to java:/jaas/security-domain/* I propose: jboss enterprise-beans entity ejb-nameSecureEJB/ejb-name jndi-nameSecureJEB/jndi-name security-configuration authentication login-module code=org.jboss.security.auth.spi.UsersRolesLoginModule flag=required/ /authentication /security-configuration /entity /jboss this make a new instance of AuthenticationManager + RealmMapping in java:comp/env/security-domain/* or for a sar (!!!): server mbean code=com.foo.AuthenticatedMBean name=com.foo:name=authenticated security-configuration authentication type=override login-module code=org.jboss.security.auth.spi.UsersRolesLoginModule flag=required/ /authentication /security-configuration /mbean /server and so on... I hope that these examples are clearer than what I wanted to say in my ugly English :-) These proposals are partially independent from the necessity to introduce JACC in jboss, we can start to code :-))) Claudio -Original Message- From: Scott M Stark [SMTP:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 8:06 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] 4.0 Roadmap The big change in the current JBoss security layer in terms of MBeans and interfaces is that the extension point for security needs to be based on the JACC apis as much as possible with any extensions we deem neccessary. Currently the contract is just the AuthenticationManager, RealmMapping. You'll have to clarify the notion of association with the j2ee component modules. -- Scott Stark Chief Technology Officer JBoss Group, LLC Vesco Claudio wrote: Hi alls! Sorry for my english... :-) I am also interested in working in the JACC area. I propose this roadmap: 1) implementing the required javax.security.jacc.* classes/interfaces in j2ee module. this javax.security.jacc.* does not depend on jboss 2) implementing a MBean that manage jacc 3) [the dirty work] rewrite/restyle the jboss security system :-) For point 3, I have in mind this proposal: - we need j2sdk 1.4 then we can remove deprecated classes - jaas authentication with javax.security.auth.conf.AppConfigurationEntry[] associated to single module (ejb, ejbjar, ear, web, sar etc) with default to parent module. in this way a ejb is self contained and we don't need to modify the global configuration - jaas authorization associated to single module with merging to parent module (so we can run ejb/sar co in a sandbox) Claudio --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache
RE: [JBoss-dev] 4.0 Roadmap
Hi alls! Sorry for my english... :-) I am also interested in working in the JACC area. I propose this roadmap: 1) implementing the required javax.security.jacc.* classes/interfaces in j2ee module. this javax.security.jacc.* does not depend on jboss 2) implementing a MBean that manage jacc 3) [the dirty work] rewrite/restyle the jboss security system :-) For point 3, I have in mind this proposal: - we need j2sdk 1.4 then we can remove deprecated classes - jaas authentication with javax.security.auth.conf.AppConfigurationEntry[] associated to single module (ejb, ejbjar, ear, web, sar etc) with default to parent module. in this way a ejb is self contained and we don't need to modify the global configuration - jaas authorization associated to single module with merging to parent module (so we can run ejb/sar co in a sandbox) Claudio -Original Message- From: Brian Stansberry [SMTP:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 6:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] 4.0 Roadmap Hi Scott, At 10:12 AM 11/8/2003 -0800, you wrote: Attached is the draft of the 4.0 roadmap. The 4.0 codebase will be the basis for the j2ee 1.4 certification work. The outline is still too coarse grained due to the fact that tasks have not been assigned. If you have interest in an area let me know so tasks can be scoped out and assigned. Thanks for sending out the roadmap. I'm relatively free at the moment and would like to help out. I'm particularly interested in working in the JSR-115 (JACC) area or the servlet/jsp/web-tier integration areas, but can help wherever needed. Best regards, Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 --- 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] [ jboss-Change Notes-672538 ] Master Configuration Service
Hi alls! I think that in the current service implementation the only way to change a mbean attribute is a restart of the service. Why does not implementing the java bean event model (property change co) in jmx... after all there is in the spec. I think that if I set a attribute to a mbean, the attribute must modify the behaviour of the service, if a dependent mbean need the feedback must listen to the attribute change event. If the service can not change the attribute it must send a exception. If a dependent service can not handle a attribute change must be send a request to a the ServiceController to be restarted or deactivated. Claudio -Original Message- From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 7:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Yes, I agree, it is up to the service to say if it knows how to implement a restart, otherwise the service controller will simply execute the restart commands as a start/stop pair against the non-compliant service. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : vendredi, 24 janvier 2003 19:04 À : [EMAIL PROTECTED] Objet : Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Logically a restart vs stop/start can make sense, but practically it may not depending on the service. The problem is a service has to be omniscient to understand how to transition old state to the new state and this can be nearly impossible if the service externalizes much of its functionality through customizable socket factories, etc. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 24, 2003 9:37 AM Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Well, then you cannot update the list of the JMX interceptors as you cycle your service, right? Otherwise, how do you cycle the ServiceContext interceptor? At one point, independently of where do you manage that, I am pretty sure that you need a part of the system that thinks I do think in a specific way because it is a restart and not a definitive stop. You don't think so? Cheers, sachay --- 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] RE: JDK 1.4 support?
OK, in my current local repository the classes are not compiled. I haven't see problems with the testsuite... A possible solution is the filtering like in connector module and the porting to jdk 1.4 of the security code of jboss. Claudio -Original Message- From: Scott M Stark [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 2:06 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RE: JDK 1.4 support? For 1.4 those classes are not required and should not even be built. They were added as a hack to test that login modules could be loaded from other than the system classpath. I'll have to think about how to get rid of the need for them rather than how to keep them in synch. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Vesco Claudio [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Greg Wilkins' [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 12:11 AM Subject: RE: [JBoss-dev] RE: JDK 1.4 support? Hi alls! With jdk1.4.1(beta) there are compiler errors when compiling security javax/** (the security implementation is changed). For jdk1.4.1, do we need the hack to the java sun classes in security module? Claudio --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: JDK 1.4 support?
Hi alls! With jdk1.4.1(beta) there are compiler errors when compiling security javax/** (the security implementation is changed). For jdk1.4.1, do we need the hack to the java sun classes in security module? Claudio -Original Message- From: Jason Dillon [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 1:38 AM To: 'Greg Wilkins'; [EMAIL PROTECTED] Subject: [JBoss-dev] RE: JDK 1.4 support? There is already 1.4 support in both 3.0 and HEAD. The jboss/connector module has some conditionals which build some javax stubs for 1.3 but not for 1.4. IMO it would be better to integrate Jetty as binary, so that we don't have to keep the build systems in syncs in addition to the sources. This will make it much easier to update when Jetty updates too. --jason -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 12:40 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: JDK 1.4 support? Jason, I want to wrap up the Jetty load balancer as a JBoss service. However the load balancer is written using the nio libraries from jdk1.4 (because why load balance if your bottle neck is a user space java.io threads on your load balancer). Can we get optional jdk1.4 support into the build environment? What I'm doing in jetty is to have a separate src1.4 tree that only gets compiled if ant can see a jdk.14 compiler. It get's compiled into classes1.4 and then an extra org.mortbay.jetty-jdk1.4.jar is built with the both the normal classes and extra (and replacement) classes from classes1.4 cheers -- Greg Wilkins[EMAIL PROTECTED]http://www.mortbay.com Mort Bay Consulting Pty. Ltd. AU.+61(0)29977 2395 Mort Bay Consulting Limited. England UK. +44(0)7092063462 --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JDK 1.4 use in JBoss
I think there are some settings (ant properties) in build.xml... You can see how to use jdk 1.3/4 in connector module. Claudio -Original Message- From: Dain Sundstrom [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 6:13 PM To: JBoss-dev Subject: [JBoss-dev] JDK 1.4 use in JBoss How are we handling JDK 1.4 use in JBoss? I want to use some of the new JDBC 3.0 APIs, but they are only in JDK 1.4. We still need to support JDK 1.3 for a long time, so how are we handling this. -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] cmp2 relations, mbeans, and the testsuite
Hi! I think, I have corrected this problem in HEAD. But until now I haven't feedback. I don't think that we need a mbean to manage relationship, but I think that Dain can give us a better response :-) Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 7:26 PM To: Dain Sundstrom; jboss-dev Subject: [JBoss-dev] cmp2 relations, mbeans, and the testsuite For me, 3.0.1 head testsuite is failing all the cmp2 tests with relationships. I think this is due to Scott's recent changes to the content of some create and start methods, although I haven't reverted the changes to make sure. I propose that we manage the dependencies between a relationship and the ejbs it relates by making the relationship into an mbean that depends on both ejb mbeans. The mbean configuration system will then call start on it only after both ejbs are started. It can call methods on each ejb mbean to set up the relationship. I haven't looked into implementing this yet. Anyone see any obvious problems with it or have any objections? 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 ___ 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] cmp2 relations, mbeans, and the testsuite
between the lines...
-Original Message-
From: David Jencks [SMTP:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 1:34 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] cmp2 relations, mbeans, and the testsuite
On 2002.06.07 03:03:41 -0400 Vesco Claudio wrote:
Hi!
I think, I have corrected this problem in HEAD.
Yes. I ported it back to 3.0. As far as I can tell it mostly reverts
scott's changes?
[Vesco Claudio] No, in the 1.36 version of JDBCStoreManager the start
method was
public void start() throws Exception
{
startCommand.execute();
// Start the query manager. At this point is creates all of the
// query commands. The must occure in the start phase, as
// queries can opperate on other entities in the application, and
// all entities are gaurenteed to be createed until the start phase.
queryManager.start();
readAheadCache.start();
}
and the create method contains all code :-(
I am stop here. I am no so expert to cmp2 :-)
But I think that we don't need a mbean for a simple bridge to the metadata.
Claudio
But until now I haven't
feedback.
I don't think that we need a mbean to manage relationship, but I think
that
Dain can give us a better response :-)
I think it is the easiest solution I have seen. The relationship object
does depend on both endpoints to be fairly well started before it can
start, that is why the init/create step has to do so much. I think that
using the mbean dependency mechanism already built into the infrastructure
is by far the simplest way to ensure this while keeping the init/create
step from referring to the outside world.
david jencks
Claudio
-Original Message-
From: David Jencks [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 7:26 PM
To: Dain Sundstrom; jboss-dev
Subject: [JBoss-dev] cmp2 relations, mbeans, and the testsuite
For me, 3.0.1 head testsuite is failing all the cmp2 tests with
relationships. I think this is due to Scott's recent changes to the
content of some create and start methods, although I haven't reverted
the
changes to make sure.
I propose that we manage the dependencies between a relationship and
the
ejbs it relates by making the relationship into an mbean that depends
on
both ejb mbeans. The mbean configuration system will then call start
on
it
only after both ejbs are started. It can call methods on each ejb
mbean
to
set up the relationship.
I haven't looked into implementing this yet. Anyone see any obvious
problems with it or have any objections?
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
___
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
___
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] I can't believe france is out of the world cup
Go Italy!!! uhmmm, can we change jboss-development in soccer-jboss? :-))) Claudio -Original Message- From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 4:30 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] I can't believe france is out of the world cup Come on, Tomasson will kick them out with 3-0 ! Ah, justice is made ! Go Italy ! Simone, I personnaly don't care much about football: I just give a little support for French. Today football, this week-end the legislative elections, pfhh... what a hard time! ;) But I am sure you know what I mean: Italian situation has strong similarities with France, but a few year earlier! ;) This new World-Cup mailing-list is cool! ___ 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] LocalManagedConnection.java Breaks Sybase
Hi alls!
This problem is triggered when it is called a stored procedure in sybase.
The stored procedure must be defined with chained transaction mode or
anymode
sql
sp_procxmode stored procedure name, 'anymode'
/sql
If the sp is called in transaction (autocommit = false), the mode must be
anymode.
I think that if the transaction mode for the method of EJB is Never the
autocommit mode is setted to false.
I have read the code which is written by David, but I have no tested this.
David, you say that if there is a managed connection the autocommit is off,
is it right?
Is this valid when we have a managed connection without transaction? Or we
have a autocommit = on?
Claudio
-Original Message-
From: David Jencks [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 6:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] LocalManagedConnection.java Breaks Sybase
Someone already reported this problem and I think found a solution. As I
recall it was in the jca forum, which I hope will be back tomorrow.
There is no autocommit setting in the rar configuration, the wrapper
implements the jca required behavior of
-- if there is a managed connection, autocommit is off (obviously)
-- if there is no managed connection, autocommit is on.
Since jdbc has the bad taste to use autocommit settings rather than
explicitly starting local transactions, a good deal of jumping through
hoops seems to be necessary. If you have a simpler way to implement this
behavior I'd like to see it.
david jencks
On 2002.06.05 00:08:34 -0400 Corby Page wrote:
I have had great success using JBoss 2.4.x with our Sybase 12
database.
But when I attempted to migrate our production system to JBoss 3.0.0, I
immediately had problems. On server startup, several of my MBeans
attempt
to
run queries against the database. Whenever they call Connection.close(),
the
code blows up with a SQLException (the text of the exception is SET
CHAINED
IS NOT ALLOWED IN MULTISTATEMENT TRANSACTIONS).
The offending code is in LocalManagedConnection.java:
void checkTransaction() throws SQLException
{
if (inManagedTransaction)
{
return;
} // end of if ()
//Not in managed transaction.
//Should we autocommit?
if (jdbcAutoCommit !con.getAutoCommit())
{
CON.SETAUTOCOMMIT(TRUE); // Emphasis Added
return;
} // end of if ()
//Autocommit should be off, is it?
if (con.getAutoCommit())
{
con.setAutoCommit(false);
} // end of if ()
}
The emphasized line is the one which throws the SQLException. If I
comment
out the line, then my entire application is able to run just fine on
3.0.
LocalManagedConnection.java seems to be a rather awkward piece of
code.
It
hardcodes the initial value of jdbcAutoCommit, and then it continually
attempts to override the connection's autocommit settings, regardless of
how
the user specifies autocommit in the RAR configuration. Sybase is
barfing
when LocalManagedConnection attempts to forcibly override the autocommit
settings again, even though Sybase thinks it should be managing the
transactional scope.
While commenting out the offending line works for me, it wouldn't
surprise
me if that introduced concerns for other users. I hope that we can find
an
elegant patch that will allow Sybase users to take advantage of JBoss
3.0.
Thanks,
Corby
_
Join the world's largest e-mail service with MSN Hotmail.
http://www.hotmail.com
___
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
___
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] LocalManagedConnection.java Breaks Sybase
OK, good :-)
-Original Message-
From: David Jencks [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 1:39 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] LocalManagedConnection.java Breaks Sybase
I should not answer messages so late at night.
What I meant to say was...
-- if there is a managed TRANSACTION, autocommit is off (obviously)
-- if there is no managed TRANSACTION, autocommit is on.
Managed transaction being one controlled by the app server/transaction
manager rather than your client code.
I think if the transaction mode is NEVER then autocommit will be on since
there is no managed transaction.
Sorry for the confusion
david jencks
On 2002.06.05 03:17:20 -0400 Vesco Claudio wrote:
Hi alls!
This problem is triggered when it is called a stored procedure in
sybase.
The stored procedure must be defined with chained transaction mode or
anymode
sql
sp_procxmode stored procedure name, 'anymode'
/sql
If the sp is called in transaction (autocommit = false), the mode must
be
anymode.
I think that if the transaction mode for the method of EJB is Never
the
autocommit mode is setted to false.
I have read the code which is written by David, but I have no tested
this.
David, you say that if there is a managed connection the autocommit is
off,
is it right?
Is this valid when we have a managed connection without transaction? Or
we
have a autocommit = on?
Claudio
-Original Message-
From: David Jencks [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 6:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] LocalManagedConnection.java Breaks
Sybase
Someone already reported this problem and I think found a solution.
As
I
recall it was in the jca forum, which I hope will be back tomorrow.
There is no autocommit setting in the rar configuration, the wrapper
implements the jca required behavior of
-- if there is a managed connection, autocommit is off (obviously)
-- if there is no managed connection, autocommit is on.
Since jdbc has the bad taste to use autocommit settings rather than
explicitly starting local transactions, a good deal of jumping through
hoops seems to be necessary. If you have a simpler way to implement
this
behavior I'd like to see it.
david jencks
On 2002.06.05 00:08:34 -0400 Corby Page wrote:
I have had great success using JBoss 2.4.x with our Sybase 12
database.
But when I attempted to migrate our production system to JBoss
3.0.0,
I
immediately had problems. On server startup, several of my MBeans
attempt
to
run queries against the database. Whenever they call
Connection.close(),
the
code blows up with a SQLException (the text of the exception is SET
CHAINED
IS NOT ALLOWED IN MULTISTATEMENT TRANSACTIONS).
The offending code is in LocalManagedConnection.java:
void checkTransaction() throws SQLException
{
if (inManagedTransaction)
{
return;
} // end of if ()
//Not in managed transaction.
//Should we autocommit?
if (jdbcAutoCommit !con.getAutoCommit())
{
CON.SETAUTOCOMMIT(TRUE); // Emphasis Added
return;
} // end of if ()
//Autocommit should be off, is it?
if (con.getAutoCommit())
{
con.setAutoCommit(false);
} // end of if ()
}
The emphasized line is the one which throws the SQLException. If I
comment
out the line, then my entire application is able to run just fine on
3.0.
LocalManagedConnection.java seems to be a rather awkward piece of
code.
It
hardcodes the initial value of jdbcAutoCommit, and then it
continually
attempts to override the connection's autocommit settings,
regardless
of
how
the user specifies autocommit in the RAR configuration. Sybase is
barfing
when LocalManagedConnection attempts to forcibly override the
autocommit
settings again, even though Sybase thinks it should be managing the
transactional scope.
While commenting out the offending line works for me, it wouldn't
surprise
me if that introduced concerns for other users. I hope that we can
find
an
elegant patch that will allow Sybase users to take advantage of
JBoss
3.0.
Thanks,
Corby
_
Join the world's largest e-mail service with MSN Hotmail.
http://www.hotmail.com
___
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
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I think that is better to have multiple conf files, this resolve the problems described by Sacha (deploy/redeploy). For the GUI problem, I think that we have already implemented jsr 77, we can start to implement jsr 88 and we can wait that SUN :-) extends netbeans to handle these specifications. Claudio -Original Message- From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 3:30 PM To: marc fleury; Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? Marc, I see your point and the interest of such a solution. Nevertheless, there is another problem in fact that *currently* favor the multiple files approach: persistent modification of configuration. Currently (as of 3.0), when you want to modify some service/bean/datasource/whatever, you take its corresponding snippet, modify it and zou, it is re-deployed. First problem: re-deploy should not be, in some cases, undeploy+deploy. Second problem: everything that is in the file is re-deployed. = if you have a single file, you redeploy everything = we tend to have many files now because, currently, many files = fine granularity of redeploy. The second category of problems is about persistence of changes. If you say: F*ck the files, we go through JMX anyway, then any modification made through JMX is *not* persisted (i.e. transient modification). This is a problem, a real problem. The old solution of keeping the old version didn't seem to work well, so it wasn't good either. = IMHO, the problem is not about one vs. multiple files, it is about granularity and persistence of changes (= granularity of redeploy) = maybe the repository approach is a good solution. But *Currently*, with these issues, the multiple-file approach is the best (only?) way to get fine-grained modification of our app server. Cheers, Sacha -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 15:19 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? You do, this is the production file. There is the development files that really has their own snippets and all and then there is the one big file for the production server approach. I believe we can do this in several steps 1- as today we recommend locking down the server configuration once you are done with development by merging the jboss-services into one big STATIC jboss-services 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are configured in one file. There are many advantages to this approach, namely you get rid of 100% of the indirection. Also it is all well in one page. We did discuss with David in January as to how to do that. 3- merge all of them, mbean,bean so the root tag is jboss mbean bean bla bla bla 4- the last gripe from the thread I am not convinced it had to do with being intimidated by mbean configuration files. I would have to think about this one, there are problems with separating creation and configuration (but it should be done imho) where the creation references a configuration by name, then the XML syntax usage should be simplified as much as possible, avoid XML verbosity, nobody likes it. 5- gui? pf it would need to be a JMX gui in our case, why not, but everybody talks about these and no-one does jack. marcf |-Original Message- |From: Sacha Labourey [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 5:55 AM |To: marc fleury; Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Well, it really depends IMHO. Would you really want to have |security information (users, groups, ...) in the same file as the |services (jboss-services.xml) ? I am not sure... | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoye : vendredi, 26 avril 2002 14:53 | A : Sacha Labourey; Juha-P Lindfors; | [EMAIL PROTECTED] | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | I totally agree with the article, I believe we should merge our | configuration files today, and get rid of the unreadable XML, ___ 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] CVS update: build/jboss build.xml
You beat me :-)))
Claudio
-Original Message-
From: Francisco Reverbel [SMTP:[EMAIL PROTECTED]]
Sent: Friday, April 19, 2002 3:25 PM
To: [EMAIL PROTECTED]
Subject: [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
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RC1 release branch occuring at 00:00
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
RE: [JBoss-dev] RC1 release branch occuring at 00:00
Until yesterday these properties were setted (CVS HEAD tuesday) In my system at work these properties does not resolve the problems (Windows NT 4.0 + sun jdk 1.4) In current implementation of jacorb we need to load the org.omg.CosNaming._NamingContextExtSub from jacorb.jar and not from boot classes, I think. Claudio -Original Message- From: Jason Dillon [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 11:54 PM To: Francisco Reverbel Cc: Scott M Stark; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton Any reason why the service can not set these props? If the JVM is an IBM one I also add $JBOSS_HOME/lib/jacorb.jar to the classpath. Why the special case for IBM? --jason ___ 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] Lets ditch the testsuite bin scripts
I think that the target compile-bin in testsuite/build.xml must be removed
or a if=HAVE_BIN_DIR must be added.
I cannot commit these patches because my current testsuite/build.xml is a
lot modified.
I think that we can remove the target compile-bin.
Or add
available property=HAVE_BIN_DIR file=${source.bin} type=dir/
near line 402 and
modify compile-bin with
target name=compile-bin depends=init if=HAVE_BIN_DIR
Claudio
-Original Message-
From: Jason Dillon [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, April 17, 2002 2:39 AM
To: David Jencks
Cc: jboss-dev
Subject: Re: [JBoss-dev] Lets ditch the testsuite bin scripts
I like them... they make me feel warm and fuzzy and that god loves me. If
you
remove them does that mean that god won't love me anymore?
* * *
Who am I kidding... there is no god, so nuke em.
--jason
Quoting David Jencks [EMAIL PROTECTED]:
Does anyone have a problem with deleting all the testsuite/src/bin
scripts?
IMO they are 200% obsolete given the current test framework.
david jencks
___
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-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RC1 release branch occuring at 00:00
I have modified build/build.xml to copy iiop-service.xml in $JBOSS_HOME/server/default/deploy, I think Francisco missed it. To Francisco, can you keep in synch HEAD with and RC1? If not I can try to test yours patches with Branch_3_0 and I synchronize the repository. Francisco, I have tested yours last commit and IT WORKS!!! great job! I have only a problem with org.jboss.test.bankiiop.test.BankStressTestCase.testMultiThread2 which kills jboss :-( I'll investigate this... Claudio -Original Message- From: Francisco Reverbel [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 6:16 PM To: David Jencks Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 On Wed, 17 Apr 2002, David Jencks wrote: ... [big snip] Hope this helps. It helps a lot! Thanks, 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
RE: [JBoss-dev] Re: Problem with ejb redeploy in remote interface in-server lookup.
Uhm!?!? This is a IIOP problem. With CVS HEAD jdk 1.4 Windows NT I don't have this problem. Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 7:02 PM To: Scott M Stark Cc: David Jencks; [EMAIL PROTECTED] Subject: [JBoss-dev] Re: Problem with ejb redeploy in remote interface in-server lookup. I'm using 1.4 on linux, both tests that use the remote interface give this exception: 2002-04-17 13:00:24,703 DEBUG [org.jboss.test.naming.ejb.TestEjbLinkBean] failed java.lang.ClassCastException at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRe moteObject.java:293) at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134) at org.jboss.test.naming.ejb.TestEjbLinkBean.testEjbLinkCaller(TestEjbLinkBea n.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Statel essSessionContainer.java:653) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(Ca chedConnectionInterceptor.java:147) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Stateless SessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercept or.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCM T.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java: 129) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.j ava:313) at org.jboss.ejb.Container.invoke(Container.java:706) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java :701) at java.lang.Thread.run(Thread.java:536) I'll check on 1.3.1 on my mac when I have a minute. david On 2002.04.17 12:48:18 -0400 Scott M Stark wrote: I don't see this as I can run the test multiple times using a clean checkout of Branch_3_0. What is the error you are seeing? [starksm@banshee testsuite]$ build.sh -Dtest=org.jboss.test.naming.test.EjbLinkUnitTestCase -Dnojars=t one-test Searching for build.xml ... Buildfile: /home/starksm/cvsroot/JBoss3.0/jboss-all/testsuite/build.xml ... one-test: [mkdir] Created dir: /home/starksm/cvsroot/JBoss3.0/jboss-all/testsuite/output/reports [mkdir] Created dir: /home/starksm/cvsroot/JBoss3.0/jboss-all/testsuite/output/log [junit] Running org.jboss.test.naming.test.EjbLinkUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.723 sec BUILD SUCCESSFUL Total time: 6 seconds [starksm@banshee testsuite]$ build.sh -Dtest=org.jboss.test.naming.test.EjbLinkU nitTestCase -Dnojars=t one-test Searching for build.xml ... Buildfile: /home/starksm/cvsroot/JBoss3.0/jboss-all/testsuite/build.xml ... one-test: [delete] Deleting: /home/starksm/cvsroot/JBoss3.0/jboss-all/testsuite/output/log/test.log [junit] Running org.jboss.test.naming.test.EjbLinkUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.611 sec BUILD SUCCESSFUL Total time: 5 seconds [starksm@banshee testsuite]$ java -version java version 1.3.1_03 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) Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-docs [EMAIL PROTECTED]; Scott Stark [EMAIL PROTECTED] Sent: Wednesday, April 17, 2002 8:12 AM Subject: Problem
RE: [JBoss-dev] RC1 release branch occuring at 00:00
Hi alls! For the testsuite. In my local cvs repository I have removed the iiop tests from stress test case and added in a new target which sets the properties to make running the iiop part. These test are called from tests target. (I have written this some mails ago :-) ) When I have time I retest alls with jdk 1.3 and if it works then I'll submit the patch or, if you like, I'll commit it directly. Francisco, can you patch org.jboss.iiop.WebCL? claudio -Original Message- From: Francisco Reverbel [SMTP:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 5:31 PM To: David Jencks Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 On Mon, 15 Apr 2002, David Jencks wrote: Sorry, I assumed that ./build.sh clean main would build everything, especially since the iiop tests appear to be running (and failing) I was not aware the iiop tests were running by default. They shouldn't, because right now they require three special actions: 1 - The RMI/IIOP MBean entry in jboss-service.xml must to be uncommmented. 2 - JBoss must be started with additional options: export JBOSS_CLASSPATH=$JBOSS_HOME/lib/jacorb.jar export JAVA_OPTS=-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton 3 - A special target (iiop-test) must be used to run iiop tests. If you do these things then the iiop tests should not fail. A question to all: Should we make 1 and 2 be the default case, so that iiop tests run with no special arrangements? Could we perhaps have the default target compile everything, and have a core target that compiles the things that are expected to work? This happened once before when I changed something that broke clustering and didn't know it since it wasn't in the main build. Yes, I think everything should compile by default. Best, Francisco Thanks david jencks On 2002.04.15 05:13:29 -0400 Scott M Stark wrote: It will have to be a seperate service release with instructions on how to incorporate because iiop is broken right now: == Executing 'most' in module 'iiop'... == _buildmagic:init: configure: init: compile-classes: [mkdir] Created dir: /home/starksm/3.0.0/jboss-all/iiop/output/classes/main [javac] Compiling 75 source files to /home/starksm/3.0.0/jboss-all/iiop/output/classes/main /home/starksm/3.0.0/jboss-all/iiop/src/main/org/jboss/iiop/WebCL.java:11: cannot resolve symbol symbol : class UnifiedClassLoader location: package system import org.jboss.system.UnifiedClassLoader; ^ /home/starksm/3.0.0/jboss-all/iiop/src/main/org/jboss/iiop/WebCL.java:29: cannot resolve symbol symbol : class UnifiedClassLoader location: class org.jboss.iiop.WebCL public WebCL(ObjectName container, UnifiedClassLoader parent) ^ /home/starksm/3.0.0/jboss-all/iiop/src/main/org/jboss/proxy/compiler/IIOPS tu bCompiler.java:107: warning: org.jboss.proxy.compiler.ProxyAssembler in org.jboss.proxy.compiler has been deprecated private static void generateMethodCode(ProxyAssembler asm, ^ /home/starksm/3.0.0/jboss-all/iiop/src/main/org/jboss/proxy/compiler/IIOPS tu bCompiler.java:107: warning: org.jboss.proxy.compiler.ProxyAssembler in org.jboss.proxy.compiler has been deprecated private static void generateMethodCode(ProxyAssembler asm, ^ /home/starksm/3.0.0/jboss-all/iiop/src/main/org/jboss/proxy/compiler/IIOPS tu bCompiler.java:251: warning: org.jboss.proxy.compiler.ProxyAssembler in org.jboss.proxy.compiler has been deprecated ProxyAssembler asm = ^ /home/starksm/3.0.0/jboss-all/iiop/src/main/org/jboss/proxy/compiler/IIOPS tu bCompiler.java:252: warning: org.jboss.proxy.compiler.ProxyAssembler in org.jboss.proxy.compiler has been deprecated new ProxyAssembler(stubClassName, ^ 2 errors 4 warnings - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, April 15, 2002 2:01 AM Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 Are you building with -Dgroups=most? Otherwise iiop will not be included in the build... or do you mean instructions on how to build configure? --jason Quoting Scott M Stark [EMAIL PROTECTED]: Then we can just post directions on how to setup and try iiop with the RC1 binary I'm building now. Next release it can be configured by default. ___ Jboss-development mailing list [EMAIL PROTECTED]
RE: [JBoss-dev] Test Suite broken?
Hi! I think that this is a jacorb problem and for now we cannot remove the -Xbootclasspath :-( If I remember well the problem is when the iiop container invoker tries to bind the ejb home into the corba naming space, it cannot create a subcontext. Claudio PS to Francisco: I have tested iiop in jdk 1.4 in my test bed with jython, it works! (deploy in jboss and calling ejb over iiop) :-) but the testsuite is still falling, today I'll try to figure why. -Original Message- From: Jason Dillon [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 11:07 PM To: Vesco Claudio Cc: 'David Jencks'; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Test Suite broken? export JAVA_OPT=-Dpolicy.expandProperties=false -Xbootclasspath/p:$JBOSS_HOME/lib/jacorb.jar We need to fix this... having to rely on non-standard -X flags to the JVM is going to be a pain in the ass... There must be a better way to get around this issue with JacORB. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Test Suite broken?
I agree with you completely with you. These hacks are only made locally in my system only for testing the great Francisco's work. When we go in production phase we need to resolve the remaining issues. Claudio -Original Message- From: Jason Dillon [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 10:45 AM To: Vesco Claudio Cc: 'David Jencks'; [EMAIL PROTECTED]; 'Francisco Reverbel' Subject: RE: [JBoss-dev] Test Suite broken? Yes, I understand this is a JacORB issue... but I suggest that there is a better way to handle the problem which they are trying to solve otherthan adding the the jvm boot classpath. I asked Francisco to look into the details further and am still waiting for information about the problem. We want to use JBoss for classloading not force users to start managing hacked archives on there boot classpath. For example, if the classes are remote (using NetBoot), we then have a problem adding the jar to the boot classpath. I think it is a REALLY BAD IDEA to special case this or any other archive just to make the system work. For example, imagine if JBoss insisted that the java.lang.String impl was broken (which it might be) and forced you to use a patched version of the VM classes for the system to work correctly... what a pain in the ass. It would have been better to handle the buggy String impl in a different fashion. Since I do not know the full details of the JacORB hack, I can not say that the case is the same, but I can say that there is a high chance that an alternative aproache could be used to solve the same problem. I think that until this is solved, we can not ship with iiop support in the default config, as there is no easy way to determie and setup this boot classpath hack. --jason Quoting Vesco Claudio [EMAIL PROTECTED]: Hi! I think that this is a jacorb problem and for now we cannot remove the -Xbootclasspath :-( If I remember well the problem is when the iiop container invoker tries to bind the ejb home into the corba naming space, it cannot create a subcontext. Claudio PS to Francisco: I have tested iiop in jdk 1.4 in my test bed with jython, it works! (deploy in jboss and calling ejb over iiop) :-) but the testsuite is still falling, today I'll try to figure why. -Original Message- From: Jason Dillon [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 11:07 PM To: Vesco Claudio Cc: 'David Jencks'; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Test Suite broken? export JAVA_OPT=-Dpolicy.expandProperties=false -Xbootclasspath/p:$JBOSS_HOME/lib/jacorb.jar We need to fix this... having to rely on non-standard -X flags to the JVM is going to be a pain in the ass... There must be a better way to get around this issue with JacORB. --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Test Suite broken?
Hi! In weekdays, I update my local cvs every morning (Italy time) at minimum. At friday I make a CD image of the cvs repository and I continue to hack jboss at home where I don't have external connection (my modem has been burnt from a lightning :-( ). So... :-) Now I have completed the testsuite with some patches to iiop tests. You have reason that the problems are in client.policy, but you can test the iiop only with (in testsuite): ./build.bat -Dtest=test iiop-test which in windows does not function (ant is called with ant -Dtest test iiop-test, the = is lost in hyperspace :-( ) If I remember well, I think this is the only mode which permits to set the java.security.manager and java.security.policy properties. So, I have integrated the iiop tests in a new target, tests-standard-stress-iiop, which invokes the tests and sets the properties. With this new target, I have obtained that the iiop testsuite run but some tests fail with a timeout error (junit error). When I have this timeout error successive calls to jboss with corba fail and jboss does not go in shutdown :-((( I think that you have a security policy file in path (Have you tested with jdk 1.4? And have you tested with jdk 1.4 in windows?) I have another question, when I allocate the ORB I have a warning (no properties file found) by jacorb, I haven't problems with my test bed in jython. I think that at least for the server part (jboss server) we need this file in the iiop sar. Claudio -Original Message- From: Francisco Reverbel [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 2:22 PM To: Vesco Claudio Cc: 'Jason Dillon'; 'David Jencks'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Test Suite broken? Hi Claudio, On Fri, 12 Apr 2002, Vesco Claudio wrote: PS to Francisco: I have tested iiop in jdk 1.4 in my test bed with jython, it works! (deploy in jboss and calling ejb over iiop) :-) That is Great! but the testsuite is still falling, today I'll try to figure why. Have you updated your tree recently? About a week ago I fixed a problem in the iiop testcases. They needed a client.policy file in order to do stub downloading (via http) from the JBoss server. I did not see the problem before because a java.policy in my home dir was already granting allPermission to everybody... Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Test Suite broken?
Hi! When I comment the org.jboss.test.bankiiop.test.BankStressTestCase.testMultiThread2 test the timeout go out and jboss can be shutdown. With my patches to the testsuite IIOP TESTS RUN OK in jdk 1.4 + windows NT :-) and I DON'T have fixed the OK result :-) I'll try to understand why testMultiThread2 kills jboss... Claudio -Original Message- From: Vesco Claudio Sent: Friday, April 12, 2002 2:58 PM To: 'Francisco Reverbel'; Vesco Claudio Cc: 'Jason Dillon'; 'David Jencks'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Test Suite broken? Hi! In weekdays, I update my local cvs every morning (Italy time) at minimum. At friday I make a CD image of the cvs repository and I continue to hack jboss at home where I don't have external connection (my modem has been burnt from a lightning :-( ). So... :-) Now I have completed the testsuite with some patches to iiop tests. You have reason that the problems are in client.policy, but you can test the iiop only with (in testsuite): ./build.bat -Dtest=test iiop-test which in windows does not function (ant is called with ant -Dtest test iiop-test, the = is lost in hyperspace :-( ) If I remember well, I think this is the only mode which permits to set the java.security.manager and java.security.policy properties. So, I have integrated the iiop tests in a new target, tests-standard-stress-iiop, which invokes the tests and sets the properties. With this new target, I have obtained that the iiop testsuite run but some tests fail with a timeout error (junit error). When I have this timeout error successive calls to jboss with corba fail and jboss does not go in shutdown :-((( I think that you have a security policy file in path (Have you tested with jdk 1.4? And have you tested with jdk 1.4 in windows?) I have another question, when I allocate the ORB I have a warning (no properties file found) by jacorb, I haven't problems with my test bed in jython. I think that at least for the server part (jboss server) we need this file in the iiop sar. Claudio -Original Message- From: Francisco Reverbel [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 2:22 PM To: Vesco Claudio Cc: 'Jason Dillon'; 'David Jencks'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Test Suite broken? Hi Claudio, On Fri, 12 Apr 2002, Vesco Claudio wrote: PS to Francisco: I have tested iiop in jdk 1.4 in my test bed with jython, it works! (deploy in jboss and calling ejb over iiop) :-) That is Great! but the testsuite is still falling, today I'll try to figure why. Have you updated your tree recently? About a week ago I fixed a problem in the iiop testcases. They needed a client.policy file in order to do stub downloading (via http) from the JBoss server. I did not see the problem before because a java.policy in my home dir was already granting allPermission to everybody... Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Test Suite broken?
In my test bed with jdk 1.4 I have only 5 failures + 63 errors. (CVS HEAD + some small patches) Claudio -Original Message- From: Chris Kimpton [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 5:23 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Test Suite broken? Hi, --- marc fleury [EMAIL PROTECTED] wrote: Guys 300 tests are broken, I would like to finish the training material so can't really be working on this, but fuck... something broke recently, must be silly. Please someone look at this, Unless it just broke, I think you are looking at the jdk1.4 test results - which have always been broken. The jdk1.3 tests show around 61 problems. Chris = -- http://www.soccer2002.org.uk __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ___ 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] Exploded archive deployment
Hi! Also I haven't looked yet the patch, but I have a proposal to the deployment system... I think we have problems with blind deploy of jar/ear/sar/war/... This problem is already met with war which are not unpacked because there is need a particular deployment by the web container. I think that we can add to org.jboss.deployment.SubDeployer interface a metod, canSubdeploy for example, which is invoked by MainDeployer before invoking unpackSubPackages. This metod return true if the sub-deployer delegate to MainDeployer to deploy the subpackages, with this we can remove the test di.shortName.endsWith(.war) at begin of unpackSubPackages. I think that when we deploy a ear, we need to control which modules deploy. For example, I can have this ear: / jboss-ejb.jar weblogic-ejb.jar I know that I can remove (in every mode :-) ) the weblogic part, but I can configure the ear with application moduleejbjboss-ejb.jarejb/module /application and I have only the jboss ejbs deployed. I return in an old mailing list thread, if I remember well, but I think that a jboss-application.xml is a better solution to the current sort system to resolve the dependencies between sar-war-ejb. In this mode we can configure a jboss-application.xml with jboss-application modulesarjboss-service1.sar/sar/module moduleejbjboss-ejb.jar/ejb/module modulesarjboss-service2.sar/sar/module ... /jboss-application My bad English have hit another time? Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 2:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Exploded archive deployment OK. I haven't looked yet but am a little worried about a couple of things, although maybe I misinterpreted your comments- 1. indefinitely nested deployments are useful and used. I don't see any reason to restrict the depth. The spec requires jar in rar in ear. 2. As I recall deploymentInfo had the info on what to watch. Is this otherwise inaccessible to the deployment scanner? Anyway, thanks for the work. I will look it over and add at least the parts I like;-). I'm glad to have someone testing and expanding some of this stuff. david jencks On 2002.04.11 02:05:44 -0400 Larry Sanderson wrote: I just submitted a bunch of patches to allow archives (sar,rar,jar,war and ear) to be deployed in their exploded form. Could someone with CVS write permissions look them over? http://sourceforge.net/tracker/index.php?func=detailaid=542341group_id=2 2866atid=376687 Thanks _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12665 ___ 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] Exploded archive deployment
I have done a simple implementation of this some days ago at home but I have got a big disk crash this sunday and I have lost the sources... :-( I think that simple with a callback to the MainDeployer.deploy we can recurse - the sub-deployer invoke a owner method, for example unpackSubPackages^H :-), and delegate to MainDeployer the deploing of subpackage by calling MainDeployer by jmx or a direct reference ? uhm, I need to think to this. If I have some time this weekend I can try to implement this. Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 7:10 PM To: Vesco Claudio Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Exploded archive deployment How about making this step in MainDeployer/SubDeployer mutually recursive? so SubDeployer calls MainDeployer to unpdack/deploy sub packages if it wants, or if it is war deployer, doesn't call. I haven't looked, but it might work. david jencks On 2002.04.11 12:49:53 -0400 Vesco Claudio wrote: Hi! Also I haven't looked yet the patch, but I have a proposal to the deployment system... I think we have problems with blind deploy of jar/ear/sar/war/... This problem is already met with war which are not unpacked because there is need a particular deployment by the web container. I think that we can add to org.jboss.deployment.SubDeployer interface a metod, canSubdeploy for example, which is invoked by MainDeployer before invoking unpackSubPackages. This metod return true if the sub-deployer delegate to MainDeployer to deploy the subpackages, with this we can remove the test di.shortName.endsWith(.war) at begin of unpackSubPackages. I think that when we deploy a ear, we need to control which modules deploy. For example, I can have this ear: / jboss-ejb.jar weblogic-ejb.jar I know that I can remove (in every mode :-) ) the weblogic part, but I can configure the ear with application moduleejbjboss-ejb.jarejb/module /application and I have only the jboss ejbs deployed. I return in an old mailing list thread, if I remember well, but I think that a jboss-application.xml is a better solution to the current sort system to resolve the dependencies between sar-war-ejb. In this mode we can configure a jboss-application.xml with jboss-application modulesarjboss-service1.sar/sar/module moduleejbjboss-ejb.jar/ejb/module modulesarjboss-service2.sar/sar/module ... /jboss-application My bad English have hit another time? Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 2:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Exploded archive deployment OK. I haven't looked yet but am a little worried about a couple of things, although maybe I misinterpreted your comments- 1. indefinitely nested deployments are useful and used. I don't see any reason to restrict the depth. The spec requires jar in rar in ear. 2. As I recall deploymentInfo had the info on what to watch. Is this otherwise inaccessible to the deployment scanner? Anyway, thanks for the work. I will look it over and add at least the parts I like;-). I'm glad to have someone testing and expanding some of this stuff. david jencks On 2002.04.11 02:05:44 -0400 Larry Sanderson wrote: I just submitted a bunch of patches to allow archives (sar,rar,jar,war and ear) to be deployed in their exploded form. Could someone with CVS write permissions look them over? http://sourceforge.net/tracker/index.php?func=detailaid=542341group_id=2 2866atid=376687 Thanks _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12665 ___ 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] Test Suite broken?
:-) starting jboss - export JAVA_OPT=-Dpolicy.expandProperties=false -Xbootclasspath/p:$JBOSS_HOME/lib/jacorb.jar this is in the mailing list and this in testsuite :-))) Index: testsuite/src/main/org/jboss/test/util/TestConnection.java === RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/util/TestConnection.java,v retrieving revision 1.2 diff -r1.2 TestConnection.java 123,127d122 // Note: The following methods have been added to make the testsuite compile // with JDK 1.4. // These methods will need to be implemented later on. // Uncomment those 12 methods to compile JBoss with JDK 1.4. /* 164,166c159 */ } \ No newline at end of file --- } Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 6:54 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Test Suite broken? So what are the patches? david jencks On 2002.04.11 12:22:39 -0400 Vesco Claudio wrote: In my test bed with jdk 1.4 I have only 5 failures + 63 errors. (CVS HEAD + some small patches) Claudio -Original Message- From: Chris Kimpton [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 5:23 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Test Suite broken? Hi, --- marc fleury [EMAIL PROTECTED] wrote: Guys 300 tests are broken, I would like to finish the training material so can't really be working on this, but fuck... something broke recently, must be silly. Please someone look at this, Unless it just broke, I think you are looking at the jdk1.4 test results - which have always been broken. The jdk1.3 tests show around 61 problems. Chris = -- http://www.soccer2002.org.uk __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ___ 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] Exploded archive deployment
Ehm, does this example deploy without the patch? I think that finding a relative container from a module is not implemented in current CVS HEAD. I have org.jboss.test.naming.test.EjbLinkUnitTestCase failing :-( Claudio - There's an example in spec (EJB2.0 - 20.3.2) with the following relative ejb-link ejb-link../products/product.jar#ProductEJB/ejb-link Does your patch still deploy product.jar? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss.net/IIOP and JBossMX integration
I have checked the iiop implementation with sun jdk 1.4 (windows NT)... If I start jboss with: JAVA_OPTS=-Dpolicy.expandProperties=false -Xbootclasspath/p:$JBOSS_HOME/lib/jacorb.jar I don't have problems in deploy. If I don't prepend jacorb.jar to the bootclasspath, I have this exception in deploy: INFO [org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.helloworld/Hello] Bound HelloWorld to helloworld/Hello INFO [STDOUT] [ ConnectionManager: found conn to target 10.213.8.193:5000 ] INFO [STDOUT] [ Bound context: helloworld ] ERROR [org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.helloworld/Hello] Cannot bind EJBHome in CORBA naming service org.omg.CORBA.NO_IMPLEMENT: vmcid: 0x0 minor code: 0 completed: No at org.jacorb.orb.CDRInputStream.read_Object(CDRInputStream.java:561) at org.omg.CosNaming.NamingContextHelper.read(NamingContextHelper.java:55) at org.omg.CosNaming._NamingContextExtStub.bind_new_context(_NamingContextExtSt ub.java:549) at org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.rebind(IIOPContainerI nvoker.java:859) at org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker.start(IIOPContainerIn voker.java:512) at org.jboss.ejb.StatelessSessionContainer.start(StatelessSessionContainer.java :206) (I have logged the stack trace of NO_IMPLEMENTED exception) Where org.omg.* are SUN classes (not jacorb classes) When I run the testsuite I have this exceptions with helloiiop (client side): java.lang.ClassCastException at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemo teObject.java:293) at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134) at org.jboss.test.helloiiop.test.HelloTimingStressTestCase.testData(HelloTiming StressTestCase.java:74) I don't have exceptions in server logs. The bankiiop does not run :-( (I think my problems, I have a FilePermission violation - M$ Windows #@##@) Claudio PS: policy.expandProperties=false is needed because I have an exception when I try to run jboss (jboss does not start). This problem is explained some days before in mailing list prepending jacorb.jar in classpath permit to deploy a ejb module with an iiop invoker. PS2: I'll try the iiop at home with linux and sun jdk 1.4... -Original Message- From: Jung , Dr. Christoph [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, April 03, 2002 4:50 PM To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] JBoss.net/IIOP and JBossMX integration Oh, I forgot to mention that I only looked at the JBoss.net code and only under JDK1.3 ... CGJ -Ursprüngliche Nachricht- Von: Vesco Claudio [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 2. April 2002 19:23 An: 'Jung , Dr. Christoph' Cc: '[EMAIL PROTECTED]' Betreff: RE: [JBoss-dev] JBoss.net/IIOP and JBossMX integration Ehm... When I try to compile the iiop module with jdk 1.4 I have this error that I try to bring back to memory since I have corrected it: at line 607 of iiop/src/main/org/jboss/ejb/plugins/iiop/server/IIOPContainerInvoker.java the exception WrongPolicy is not raised Does create_reference_with_id not raise WrongPolicy in jdk 1.4? When I run the testsuite I have ClassPathException exceptions, if you want I send you the log... Claudio -Original Message- From: Jung , Dr. Christoph [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 6:20 PM To: '[EMAIL PROTECTED]' Subject:AW: [JBoss-dev] JBoss.net/IIOP and JBossMX integration Hi Adrian, Just a quick feedback. Compilation is ok, most stuff runs fine and faster ;-) From what I saw, the reflection of the Mbean interfaces in jboss-jmx seems to differ from jmxri.jar ... Because I use to define first client-side (non-Mbean) interfaces from which the Mbean interfaces are extended, I know run into ReflectionException(NoSuchMethodException) when trying to invoke those methods via MBeanServer.invoke I have to check how to work-around this issue. I have no idea what the spec says to this pattern. Best, CGJ ___ 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] JBoss.net/IIOP and JBossMX integration
Hi! I need to merge the differences from current cvs head and my repository... recompile and rerunning the testsuite. I run the testsuite in my Windows NT and so I don't have thread problems (I'll test at home with linux and jdk 1.3/4). With jdk1.3 in Windows I have met a bug known of rmi when I try to generate the iiop stubs and so I run jdk 1.4 in windows, which is also my target environment. I'll send you the log of helloiiop and bankiiop testcases. Claudio PS: the exceptions are in javax.rmi.PortableRemoveObject.narrow - ClassCastException -Original Message- From: Francisco Reverbel [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 11:52 PM To: Vesco Claudio Cc: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss.net/IIOP and JBossMX integration On Tue, 2 Apr 2002, Vesco Claudio wrote: When I try to compile the iiop module with jdk 1.4 I have this error that I try to bring back to memory since I have corrected it: at line 607 of iiop/src/main/org/jboss/ejb/plugins/iiop/server/IIOPContainerInvoker.java the exception WrongPolicy is not raised Does create_reference_with_id not raise WrongPolicy in jdk 1.4? It does not. And jdk 1.4 is correct on this, I've just checked the CORBA spec. Seems that there was a change in the spec on this particular point, and 1.4 complies with the updated spec. I've changed IIOPContainerInvoker so that it now compiles with jdk 1.4. When I run the testsuite I have ClassPathException exceptions, if you want I send you the log... Yes, I would like to look at the log. Are you trying to run the iiop testcases (helloiiop and bankiiop) with jdk 1.4? They do not run with jdk 1.4 yet. Should run with jdk 1.3 though. On Linux I suggest the IBM release of jdk 1.3. It has always worked well for me. With the Sun jdk releases (either 1.3 or 1.4) you may run out of threads, depending on your Linux kernel. Please send me the log. I would like to check if you're running into a known 1.4 problem or if this is a new one. Cheers, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Todo: multiple instances detection
Uhm... We can't start also the web container... I don't think that we would start the web container with 8080+n :-( Claudio -Original Message- From: marc fleury [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, April 03, 2002 6:10 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] Todo: multiple instances detection there should be a service that is part of the first services coming up and that detects if other JBoss systems are running on the same physical machines, this is to avoid port conflict as some services are holding on to some ports (e.g. naming on 1099, detached RMI, clustered RMI). We would then not start the naming as a duplicate nor the detached RMI but we would use the clustered RMI by increasing the connection port. This will enable people to run multiple instances of JBoss without having to manually change the stuff all the time. At least on the services we provide we should show how these behave. marcf ___ 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] JBoss.net/IIOP and JBossMX integration
Ehm... When I try to compile the iiop module with jdk 1.4 I have this error that I try to bring back to memory since I have corrected it: at line 607 of iiop/src/main/org/jboss/ejb/plugins/iiop/server/IIOPContainerInvoker.java the exception WrongPolicy is not raised Does create_reference_with_id not raise WrongPolicy in jdk 1.4? When I run the testsuite I have ClassPathException exceptions, if you want I send you the log... Claudio -Original Message- From: Jung , Dr. Christoph [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 6:20 PM To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] JBoss.net/IIOP and JBossMX integration Hi Adrian, Just a quick feedback. Compilation is ok, most stuff runs fine and faster ;-) From what I saw, the reflection of the Mbean interfaces in jboss-jmx seems to differ from jmxri.jar ... Because I use to define first client-side (non-Mbean) interfaces from which the Mbean interfaces are extended, I know run into ReflectionException(NoSuchMethodException) when trying to invoke those methods via MBeanServer.invoke I have to check how to work-around this issue. I have no idea what the spec says to this pattern. Best, CGJ ___ 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] CVS HEAD doesn't start with jdk 1.4 ?
Hi alls! Have you recompiled with jdk 1.4? Claudio -Original Message- From: Ricardo Argüello [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, March 27, 2002 8:16 AM To: Francisco Reverbel; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS HEAD doesn't start with jdk 1.4 ? I have the same problem. JBoss 3.0.0beta2 (CVS HEAD) gives me the same exception with JDK 1.4 on Windows 2000. Ricardo - Original Message - From: Francisco Reverbel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 6:23 PM Subject: [JBoss-dev] CVS HEAD doesn't start with jdk 1.4 ? It may not be a good idea to ask such a thing while people are celebrating at JBossOne... :-) Anyway, is this happening with somebody else? Or is it just with me? I am running jdk 1.4 on Linux. The relevant log excerpt is included below. Best, Francisco PS: So Marc had to attend the award ceremony while everybody else was having a party at JBossOne? ;-) log excerpt --- 2002-03-26 20:05:43,946 INFO [org.jboss.security.plugins.SecurityConfig] Starting 2002-03-26 20:05:44,124 ERROR [org.jboss.security.plugins.SecurityConfig] Starting failed java.lang.SecurityException: Configuration Error: Line 60: system property [] expanded to empty value at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:97) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcc essorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstr uctorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:296) at java.lang.Class.newInstance(Class.java:249) at javax.security.auth.login.Configuration$3.run(Configuration.java:221) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.Configuration.getConfiguration(Configuration.jav a:215) at org.jboss.security.plugins.DefaultLoginConfig.getConfiguration(DefaultLogi nConfig.java:78) at org.jboss.security.plugins.DefaultLoginConfig.invoke(DefaultLoginConfig.ja va:155) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:441) at org.jboss.security.plugins.SecurityConfig.installConfig(SecurityConfig.jav a:138) at org.jboss.security.plugins.SecurityConfig.pushLoginConfig(SecurityConfig.j ava:106) at org.jboss.security.plugins.SecurityConfig.startService(SecurityConfig.java :79) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDisp atcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:441) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.j ava:673) at $Proxy1.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:280) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDisp atcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:441) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:169) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:276) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:500) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:463) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:445) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDisp atcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:441) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:320) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:208) at org.jboss.Main.boot(Main.java:138) at org.jboss.Main$1.run(Main.java:371) at java.lang.Thread.run(Thread.java:536) Caused by:
RE: [JBoss-dev] CVS HEAD doesn't start with jdk 1.4 ?
OK, I have recompiled in Windows NT jboss with jdk 1.4 and I have the exception. Quick and dirty hack: start jboss with JAVA_OPTS=-Dpolicy.expandProperties=false (see jboss.bat or jboss.sh) or modify conf/auth.conf + db/hypersonic/default.script as martin has written. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS HEAD doesn't start with jdk 1.4 ?
Sorry for my English :-)
-Original Message-
From: Peter Fagerlund [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, March 27, 2002 4:05 PM
To: Vesco Claudio; '[EMAIL PROTECTED]'
Subject: Re: [JBoss-dev] CVS HEAD doesn't start with jdk 1.4 ?
on 27-03-2 15.33, Vesco Claudio at [EMAIL PROTECTED] wrote:
+ db/hypersonic/default.script as martin has written.
whats that ? where ?
--
The problem is in the parsing of conf/auth.conf. jboss-sdk1.4 crashes
when parses this fragment:
// Security domain for testing new jca framework
DefaultDbRealm {
//
// Security domain for new jca framework.
// One per ManagedConnectionFactory are required.
org.jboss.resource.security.ConfiguredIdentityLoginModule required
principal=sa
userName=sa
password=
managedConnectionFactoryName=jboss.jca:service=LocalTxCM
;
};
If you changes password= by password=xxx then it starts ok, but you
have to modify passord in Default Db conforming to this by changing this
line in db/hypersonic/default.script from:
CREATE USER SA PASSWORD ADMIN
to:
CREATE USER SA PASSWORD xxx ADMIN
This worked to me, but is really weird
Xavi
---
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MEJB transactions (invoke deploy)
Hi alls! When I try to deploy an ear (better, an CMP entity) with MEJB I have an exception in org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand because this class try to start a new transaction. The problem is that MEJB have a transaction management setting to default (Container). I think that is better to set the transaction to Bean. In jsr-77 I don't have found reference to the transaction mode of the management EJB. When I modify the transaction definition, the deployment go well. Another problem... There is an discrepancy with the pdf jsr-77. The method queryNames in the interface javax.management.j2ee.Management have a query parameter in jsr-77 pdf which is not present in the current implementation. If not there are controindications, I'll commit the patches. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MEJB transactions (invoke deploy)
I remember you that my English is very bad :-) In org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand at line 143 there is manager.getContainer().getTransactionManager().begin (); If the container is already in transaction there is an exception (javax.transaction.NotSupportedException) because there is another transaction. The container have a transaction active because, I think, I have deployed the entity with MEJB SSB and the method invoke of this ejb have a transaction defined in the transaction assembly part of ejb-jar.xml, more there is not definitions and so the defaults are applied. The CMP engine start a new transaction because it need it for creating a sql table or a sql fk. I think that the transaction is only started when the ejb need a new sql table (deploy time). With others JMX remote invokers, I think there are no problems because the transaction context is not propagate from client (external jboss) and jboss. I have added transaction-type=Bean to jboss/management/mejb/ManagementBean.java and I can now deploy the entity ejb. This is the best solution that it has come to me in mind. The alternative was that to control if active transaction existed already :-( but I think that there are many place in jboss where a jmx invocation trigger a transaction begin/commit. I remember you that I don't mean a user client ejb invocation. I checked the jsr-77 and I don't see restriction to set the transaction of MEJB to Bean managed. Claudio -Original Message- From: marc fleury [SMTP:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 1:33 PM To: Vesco Claudio; Jboss Dev (Posta elettronica) Subject: RE: [JBoss-dev] MEJB transactions (invoke deploy) the container/bean story does not sound right why does the CMP engine START a new transaction? that is not it's place what persistence engine are you using? marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Vesco |Claudio |Sent: Friday, March 22, 2002 1:29 AM |To: Jboss Dev (Posta elettronica) |Subject: [JBoss-dev] MEJB transactions (invoke deploy) | | |Hi alls! | |When I try to deploy an ear (better, an CMP entity) with MEJB I have an |exception in org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand because this |class try to start a new transaction. | |The problem is that MEJB have a transaction management setting to default |(Container). | |I think that is better to set the transaction to Bean. | |In jsr-77 I don't have found reference to the transaction mode of the |management EJB. | |When I modify the transaction definition, the deployment go well. | |Another problem... | |There is an discrepancy with the pdf jsr-77. The method queryNames in the |interface javax.management.j2ee.Management have a query parameter in jsr-77 |pdf which is not present in the current implementation. | |If not there are controindications, I'll commit the patches. | | Claudio | |___ |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] MEJB transactions (invoke deploy)
Ehm... when I wrote, I think to the current jboss 3.0 rabbit hole HEAD CVS. CMP - new CMP 2.0 MEJB - management ejb - standard jsr-77 ejb connector - this ejb is deployed when jboss is started. The problem is what transaction demarcation must have MEJB (ejb/mgmt/MEJB)? I think bean managed transaction, now we have container managed transaction. If it is not then we must check every jmx exposed operations. These operations must not start a transaction because these operations does not have been called by the ejb adapter :-( I know that you help write jsr-77, but in pdf jsr-77 there is no written restriction with bean-managed or container-managed transaction. Claudio -Original Message- From: marc fleury [SMTP:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 3:01 PM To: Vesco Claudio; Jboss Dev (Posta elettronica) Subject: RE: [JBoss-dev] MEJB transactions (invoke deploy) wait wait wait a persistence engine this is a SSB... where does CMP come in? I really can't make sense of your story. marcf |-Original Message- |From: Vesco Claudio [mailto:[EMAIL PROTECTED]] |Sent: Friday, March 22, 2002 5:36 AM |To: Jboss Dev (Posta elettronica) |Cc: 'marc fleury' |Subject: RE: [JBoss-dev] MEJB transactions (invoke deploy) | | |I remember you that my English is very bad :-) | |In org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand at line 143 there is | |manager.getContainer().getTransactionManager().begin (); | |If the container is already in transaction there is an exception |(javax.transaction.NotSupportedException) because there is another |transaction. | |The container have a transaction active because, I think, I have deployed |the entity with MEJB SSB and the method invoke of this ejb have a |transaction defined in the transaction assembly part of ejb-jar.xml, more |there is not definitions and so the defaults are applied. | |The CMP engine start a new transaction because it need it for |creating a sql |table or a sql fk. |I think that the transaction is only started when the ejb need a new sql |table (deploy time). | |With others JMX remote invokers, I think there are no problems because the |transaction context is not propagate from client (external jboss) |and jboss. | |I have added transaction-type=Bean to |jboss/management/mejb/ManagementBean.java and I can now deploy the entity |ejb. | |This is the best solution that it has come to me in mind. | |The alternative was that to control if active transaction existed already |:-( but I think that there are many place in jboss where a jmx invocation |trigger a transaction begin/commit. I remember you that I don't mean a user |client ejb invocation. | |I checked the jsr-77 and I don't see restriction to set the transaction of |MEJB to Bean managed. | | Claudio | | -Original Message- | From: marc fleury [SMTP:[EMAIL PROTECTED]] | Sent: Friday, March 22, 2002 1:33 PM | To:Vesco Claudio; Jboss Dev (Posta elettronica) | Subject: RE: [JBoss-dev] MEJB transactions (invoke deploy) | | the container/bean story does not sound right | | why does the CMP engine START a new transaction? that is not it's place | what | persistence engine are you using? | | | marcf | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On Behalf Of Vesco | |Claudio | |Sent: Friday, March 22, 2002 1:29 AM | |To: Jboss Dev (Posta elettronica) | |Subject: [JBoss-dev] MEJB transactions (invoke deploy) | | | | | |Hi alls! | | | |When I try to deploy an ear (better, an CMP entity) with MEJB I have an | |exception in org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand |because this | |class try to start a new transaction. | | | |The problem is that MEJB have a transaction management setting |to default | |(Container). | | | |I think that is better to set the transaction to Bean. | | | |In jsr-77 I don't have found reference to the transaction mode of the | |management EJB. | | | |When I modify the transaction definition, the deployment go well. | | | |Another problem... | | | |There is an discrepancy with the pdf jsr-77. The method |queryNames in the | |interface javax.management.j2ee.Management have a query parameter in | jsr-77 | |pdf which is not present in the current implementation. | | | |If not there are controindications, I'll commit the patches. | | | | Claudio | | | |___ | |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] MEJB transactions (invoke deploy)
Uhm... I am checking EJB 2.0 spec, topic 17, in particular 17.3.1, 17.6.1 - 17.6.5 Bean managed tx is when the tx can be started or no which is the our case :-) MEJB is a session stateless and so the eventually inner tx must terminate before the metod completation (our case) When we have Bean managed tx the container must suspend the client tx association and now MEJB can do what it wants :-) (our case) I think that bean managed is better because is more future portable (TM) :-))) Claudio PS: I can retest jboss with MEJB with tx container managed not supported, but I think that jboss works equally -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 6:26 PM To: Vesco Claudio Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MEJB transactions (invoke deploy) I think this is inappropriate use of bean managed transactions. As far as I know the MEJB is not in fact starting any transactions, and all its operations are expected to be not in a transaction. This is what NotSupported is for. Bean managed tx is for when your bean actually needs to start transactions itself. Here, as far as I can tell, the MEJB needs there to be NO tx, it does not have any intention of starting one itself. If it did, it would have failed long ago when it tried to with cmt on. david jencks On 2002.03.22 12:11:22 -0500 Vesco Claudio wrote: Why not set tx attribute to Bean managed? No Container NotSupported I think that the inner container operations can do everything and so the transactions must be bean managed. I have tested jboss with this transaction demarcation (Bean) and I don't have problems. If there is not problems I'll commit the patch... Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 5:55 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MEJB transactions (invoke deploy) I think the tx attributes on MEJB need to be NOT SUPPORTED I think what is happening is that MEJB is creating a tx context which is getting propagated through the deployment system (same thread). Normally deployment does not include setting a tx context. Either that or we make deployment explicitly a transactional operation -- a good idea but not for today perhaps. david jencks On 2002.03.22 10:14:17 -0500 marc fleury wrote: |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Vesco |Claudio |Sent: Friday, March 22, 2002 6:52 AM |To: 'marc fleury' |Cc: Jboss Dev (Posta elettronica) |Subject: RE: [JBoss-dev] MEJB transactions (invoke deploy) | | |Ehm... | |when I wrote, I think to the current jboss 3.0 rabbit hole HEAD CVS. | |CMP - new CMP 2.0 77 is just a proxy to the JMX base, THERE SHOULD NOT BE PERSISTENCE. Try to fix the configuration to put in a fake CMP engine that just does nothing. In fact is it an entity at all? andreas? marcf ___ 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] MEJB transactions (invoke deploy)
Yes!
I want to deploy a ear (which contains a module which contains a CMP EJB) by
MEJB
simple in java:
mejb.invoke(new ObjectName(jboss.system:service=MainDeployer),
deploy,
new Object[] { new URL(file:path-ear) },
new String[] { String.getName() });
in jython :-))):
import java, javax
from javax.naming import *
from javax.management import *
from java.lang import *
from java.lang.reflect import *
mejb = InitialContext().lookup(ejb/mgmt/MEJB).create()
ARGS = Array.newInstance(Object, 1)
SIGN = Array.newInstance(String, 1)
ARGS[0] = URL(file:path-ear)
SIGN[0] = URL.getName()
mejb.invoke(ObjectName(jboss.system:service=MainDeployer), deploy, ARGS,
SIGN)
I LOVE JYTHON :-)))
:-)
Claudio
PS: I am vEsco Claudio, Vasco is a famous italian singer :-)))
-Original Message-
From: Andreas Schaefer [SMTP:[EMAIL PROTECTED]]
Sent: Friday, March 22, 2002 6:56 PM
To: Vesco Claudio
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] MEJB transactions (invoke deploy)
Hi Vasco
When I try to deploy an ear (better, an CMP entity) with MEJB I have an
exception in org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand because
this
class try to start a new transaction.
What does this mean ? How you are going to deploy a CMP entity bean with
MEJB ??
Andy
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MEJB transactions (invoke deploy)
Sorry for this, but I have thought that the MEJB can be a SECURE way to
manage jboss.
If this is not the right way to do, ok sorry.
But I think that since this the possibility to invoke every exported jmx
resource, we must check :-)
Please peace :-)
Claudio
PS: I haven't posted exceptions log because it seemed me a little problem
with a very simple solution (one line java).
I think that in the current email thread the problem is sufficiently
described.
-Original Message-
From: Andreas Schaefer [SMTP:[EMAIL PROTECTED]]
Sent: Friday, March 22, 2002 7:15 PM
To: Vesco Claudio
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] MEJB transactions (invoke deploy)
You @#!
MEJB is not to be used this way
!!
Don't ever use MEJB to access the MBeanServer. Use the
EJB-Adaptor/Connector
for this but don't spoil our time with this fucking miss-use of services !
mejb.invoke(new ObjectName(jboss.system:service=MainDeployer),
deploy,
new Object[] { new URL(file:path-ear) },
new String[] { String.getName() });
Can you dig this ?
Andy
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MEJB transactions (invoke deploy)
OK!
Sorry for the noise :-)
At home I have already the three lines of code that dig the bug in CMP2 :-)
Now I am at work
This is the other solution :-) The Right Solution
I'll send the patch to Dain...
Claudio
-Original Message-
From: marc fleury [SMTP:[EMAIL PROTECTED]]
Sent: Friday, March 22, 2002 7:56 PM
To: Vesco Claudio; 'Andreas Schaefer'
Cc: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] MEJB transactions (invoke deploy)
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Vesco
|Claudio
|Sent: Friday, March 22, 2002 10:11 AM
|To: 'Andreas Schaefer'
|Cc: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] MEJB transactions (invoke deploy)
|
|
|Yes!
|
|I want to deploy a ear (which contains a module which contains a
|CMP EJB) by
|MEJB
Ok this has NOTHING to do with the MEJB, leave the MEJB at supports and
clearly wanting to fix this at the MEJB level proves you are a reckless
young man that doesn't think a second.
OK what you want to do is have the initialization of the Bean in the CMP
engine (the deploy) CHECK for the presence of a transaction. SO if the
deployment is transactional (as done with a Required in MEJB) then you
need
to check for that transaction and only start if not present.
It is a fix in the CMP initialization code, and that is Dain's domain.
Claudio, you were right on the line that barf, really wrong on the MEJB
solution, for penitence can you give Dain the 3 lines diff that achieves
this behavior (only start transaction if not present in the initialization
of the code from Dain)
marcf
|
|simple in java:
|
|mejb.invoke(new ObjectName(jboss.system:service=MainDeployer),
| deploy,
| new Object[] { new URL(file:path-ear) },
| new String[] { String.getName() });
|
|in jython :-))):
|
|import java, javax
|
|from javax.naming import *
|from javax.management import *
|from java.lang import *
|from java.lang.reflect import *
|
|mejb = InitialContext().lookup(ejb/mgmt/MEJB).create()
|ARGS = Array.newInstance(Object, 1)
|SIGN = Array.newInstance(String, 1)
|ARGS[0] = URL(file:path-ear)
|SIGN[0] = URL.getName()
|mejb.invoke(ObjectName(jboss.system:service=MainDeployer),
|deploy, ARGS,
|SIGN)
|
|I LOVE JYTHON :-)))
|
|:-)
|
| Claudio
|
|PS: I am vEsco Claudio, Vasco is a famous italian singer :-)))
|
| -Original Message-
| From: Andreas Schaefer [SMTP:[EMAIL PROTECTED]]
| Sent: Friday, March 22, 2002 6:56 PM
| To:Vesco Claudio
| Cc:[EMAIL PROTECTED]
| Subject: Re: [JBoss-dev] MEJB transactions (invoke deploy)
|
| Hi Vasco
|
| When I try to deploy an ear (better, an CMP entity) with MEJB I have
an
| exception in org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand because
| this
| class try to start a new transaction.
|
| What does this mean ? How you are going to deploy a CMP entity bean
with
| MEJB ??
|
| Andy
|
|
|___
|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] Multiple server configurations
This is a very nice idea!!! Claudio -Original Message- From: marc fleury [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 6:09 PM To: David Jencks; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Multiple server configurations |2. I thought marc had an idea of separating the container and interceptor |stack from the invoker, so many invokers could use the same |container/stack/ejb. I think this is a more promising way to go -- you can |say all my ejbs should be invokable from JRMP and IIOP or one or the |other individually. | |I may have missed something here, let me know. It is not just an idea, this is implemented for the past 5 months or so, it is one of those new JBoss 3.0 powerful features that we need to clearly document. marcf | |david jencks | | |On 2002.03.20 10:08:48 -0500 Francisco Reverbel wrote: | On Tue, 19 Mar 2002, Jason Dillon wrote: | | Useful, yes... practical... probably not. With the current system | configuration this would be difficult to implement and still provide a | consistent view of the basic configuration attributes. | | I don't see this very clearly... Wouldn't be mostly a matter of setting | up more than one MainDeployer, each seeing a different standardjboss.xml | resource? | | It seems like you want to provide an easy way to enable/disable jrmp | iiop... it might be better to define some system properties to control | this. Perhaps then use a switchable interceptor to handle the | invocation layer? This way there is only one set of standard | configurations which are both rmi and iiop capable depending on the | value of some set of properties. | | Well, multiple server configurations are not strictly necessary. | They could be convenient in some situations, just that. | | JBoss already provides ways to switch between JRMP IIOP. Right now you | can pick one of the following options: | | 1) change jboss.xml within your EJB jars, or | | 2) (if you do not want to change your EJB jars) | use a separate JBoss server, whose configuration renders unnecessary | any changes the jboss.xml files in your EJB jars. | | My suggestion aimed at avoiding both the need for changes in your EJB | jars | and the need for a separate JBoss server. You switchable interceptor | hint | sounds interesting, but where the switch control would be? If it would | be | in the jboss.xml files within your EJB jars, then it buys us nothing. | | Or something... I don't know, but I would not like to see the system | augmented to support multipule configurations as you show in your | example. | | I will not try to push my idea on you, as I really do not know how useful | it | would be in real scenarios. | | Best, | | 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-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] Ordering part 2 :-)
Hi alls! I have only ugly logs. If you ignore the exceptions I think that the problem is not resolved. Marc says to resolve the problem. I proposed a solution but this solution have future disadvantages :-( With the patches applied at MainDeployer I don't see problems in testsuite, but I don't commit the patch in MainDeployer, I think that this must be assigned to a main developer. I commit only small fixes :-) Claudio -Original Message- From: Andreas Schaefer [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 2:12 AM To: marc fleury; David Jencks; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Scott McLaughlin Subject: Re: [JBoss-dev] Ordering part 2 :-) Hi Claudio The unnecessary exceptions previously reported by JSR-77 is ingored now. Please can you check your example to see if this solves your problem and if not please can you provide me with your log-file, thanx. Have a nice day - Andy - Original Message - From: marc fleury [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED]; David Jencks [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Scott McLaughlin [EMAIL PROTECTED] Sent: Monday, March 18, 2002 3:22 PM Subject: RE: [JBoss-dev] Ordering part 2 :-) please remove the exceptions on 77, if you try a service and redeploy we get a nasty instance found ... I say it because I saw it in london, please take care of the redeploy problems with the 77 stuff, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Ordering part 2 :-)
Hi alls! I think we have a little bug in MainDeployer. I'll try to explain the problem in my bad English :-( When I deploy redeploy an ear I have an JSR-77 exception (javax.management.InstanceNotFound) because: deploy init init current deployer invoked init subdeployers invoked create create subdeployers invoked create current deployer invoked start start subdeployers invoked start current deployer invoked undeploy stop stop current deployer invoked stop subdeployers invoked destroy destroy current deployer invoked destroy subdeployers invoked I think the right order is: deploy init (ok) init current init subdeployers create create current create subdeployers start start current start subdeployers undeploy stop stop subdeployers stop current destroy destroy subdeployers destroy current When I have modified the MainDeployer with this new order the exception has not been take place. If Marc is of agreement can apply the patch or I can post it. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Ordering part 2 :-)
If you try to make the deploy of a ear, then you make the undeploy and therefore you make the deploy of the same one ear, comes written in log one exception. In this moment, I don't have the possibility to give you a better example, but I think you can reproduce the exception with the above operations. I think that the problem is that in the management of the resources jsr77 it does not come created the resource before father but tries to create the dependent resources. With the changed order, the exception does not happen. The proposed resolution does not resolve the problem discussed in the maillist, but resolves an other problem. Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 1:51 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Ordering part 2 :-) What exactly is the problem you are having? Can you post a small detailed example? As I understand your proposal you want to deploy from the outside in rather than the inside out. I think this won't work for most packages: for instance I don't think we can put our sar packages inside ejb-jars so they could get deployed after the ejb-jar, whereas you can put an ejb-jar inside a sar to get it deployed before the sar. Please explain further. david jencks On 2002.03.18 04:19:56 -0500 Vesco Claudio wrote: Hi alls! I think we have a little bug in MainDeployer. I'll try to explain the problem in my bad English :-( When I deploy redeploy an ear I have an JSR-77 exception (javax.management.InstanceNotFound) because: deploy init init current deployer invoked init subdeployers invoked create create subdeployers invoked create current deployer invoked start start subdeployers invoked start current deployer invoked undeploy stop stop current deployer invoked stop subdeployers invoked destroy destroy current deployer invoked destroy subdeployers invoked I think the right order is: deploy init (ok) init current init subdeployers create create current create subdeployers start start current start subdeployers undeploy stop stop subdeployers stop current destroy destroy subdeployers destroy current When I have modified the MainDeployer with this new order the exception has not been take place. If Marc is of agreement can apply the patch or I can post it. Claudio ___ 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] Ordering part 2 :-)
It does not stop deploy/redeploy, only produce an exception in log. I test the testsuite now :-) Per quanto riguarda la discussione che avvenuta a riguardi dell'ordinamento, penso che le dipendenze tra risorse debbano essere indicate in un jboss-application.xml Concerning the recently discussion, I think that the dependecies between resources must be included in application-jboss.xml. The order proposed in MainDeployer I think is this correct KISS :-) If I have a ear containing sar containing ear etc etc etc, it does not standard (j2ee compliant) and so - application-jboss.xml :-) Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 5:22 PM To: Vesco Claudio Subject: Re: [JBoss-dev] Ordering part 2 :-) Does this actually stop undeployment/redeployment or only produce an ugly log? Previously Andy indicated (I think) that the jsr-77 stuff should not impede redeployment, no matter how many errors it put in the log. I am _very_ worried about reversing the order of subdeployment nesting without a more complete dependency mechanism. If this is not stopping redeployment I would prefer to leave it till I can think about it more carefully. Have you seen what happens with your change with 1. the testsuite and 2. more complicated packaging such as ear containing sar containing ear containing rar? Thanks david jencks On 2002.03.18 09:48:08 -0500 Vesco Claudio wrote: Only for you :-) I have deployed bench.ear from testsuite and when I undeploy it I have this exception, ehm zipped :-) With call reordering I don't have exception :-) Claudio undeploy-exception.zip Patch.zip -Original Message- From: Vesco Claudio [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:27 PM To: 'David Jencks'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Ordering part 2 :-) I'll retest jboss without my patchs :-) please wait a moment :-) -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:24 PM To: [EMAIL PROTECTED] Subject:Re: [JBoss-dev] Ordering part 2 :-) Could you please show the exception you are seeing in the log. This will help me 1. understand without having to reproduce the problem what you are writing about. 2. If I do attempt to reproduce the problem, indicate to me that I have found the same problem you are working with. Have you seen this problem with any .ears from the testsuite? Thanks david jencks On 2002.03.18 08:35:57 -0500 Vesco Claudio wrote: If you try to make the deploy of a ear, then you make the undeploy and therefore you make the deploy of the same one ear, comes written in log one exception. In this moment, I don't have the possibility to give you a better example, but I think you can reproduce the exception with the above operations. I think that the problem is that in the management of the resources jsr77 it does not come created the resource before father but tries to create the dependent resources. With the changed order, the exception does not happen. The proposed resolution does not resolve the problem discussed in the maillist, but resolves an other problem. Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 1:51 PM To: [EMAIL PROTECTED] Subject:Re: [JBoss-dev] Ordering part 2 :-) What exactly is the problem you are having? Can you post a small detailed example? As I understand your proposal you want to deploy from the outside in rather than the inside out. I think this won't work for most packages: for instance I don't think we can put our sar packages inside ejb-jars so they could get deployed after the ejb-jar, whereas you can put an ejb-jar inside a sar to get it deployed before the sar. Please explain further. david jencks On 2002.03.18 04:19:56 -0500 Vesco Claudio wrote: Hi alls! I think we have a little bug in MainDeployer. I'll try to explain the problem in my bad English :-( When I deploy redeploy an ear I have an JSR-77 exception (javax.management.InstanceNotFound) because: deploy init init current deployer invoked init subdeployers invoked create create subdeployers invoked create current deployer invoked start start subdeployers invoked
RE: [JBoss-dev] Ordering part 2 :-)
I have run the testsuite. I have confronted the result with http://www.lubega.com/testarchive/reports-20020318-0547/ I have errors in org.jboss.test.jmx.test, = lubega. I have *no* errors in org.jboss.test.management.test, = lubega I have errors in org.jboss.test.readahead.test.ReadAheadUnitTestCase != lubega entity already found remainder = lubega :-) I think is better to create/start an outer container before an inner container - an inner container *is* contained in the outer container. I think this is not only better for jsr 77 but better for deploying/classloading etc etc etc, but I don't know everything in jboss :-))) Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 6:05 PM To: Vesco Claudio Cc: Jboss Dev Subject: Re: [JBoss-dev] Ordering part 2 :-) On 2002.03.18 11:46:32 -0500 Vesco Claudio wrote: It does not stop deploy/redeploy, only produce an exception in log. I test the testsuite now :-) Thanks Per quanto riguarda la discussione che avvenuta a riguardi dell'ordinamento, penso che le dipendenze tra risorse debbano essere indicate in un jboss-application.xml Concerning the recently discussion, I think that the dependecies between resources must be included in application-jboss.xml. The order proposed in MainDeployer I think is this correct KISS :-) I think there are arguments in favor of both orders. If I have a ear containing sar containing ear etc etc etc, it does not standard (j2ee compliant) and so - application-jboss.xml :-) True, but some nesting is allowed by j2ee, and needs to be handled without any jboss-application.xml needed. I think that most of these problems will go away when we can represent most dependencies as (automatically generated) mbean dependencies. I think we will be able to deploy just about anything packaged in just about any nesting without needing explicit deployment instructions. btw, I think two possible fixes I would be happier with are 1. jsr 77 mbeans destroy all their children when they are destroyed. 2. create, and start steps remain ordered from inside to outside, stop step remains ordered from outside to inside, destroy step is reversed to from inside to outside. Thanks david jencks Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 5:22 PM To: Vesco Claudio Subject: Re: [JBoss-dev] Ordering part 2 :-) Does this actually stop undeployment/redeployment or only produce an ugly log? Previously Andy indicated (I think) that the jsr-77 stuff should not impede redeployment, no matter how many errors it put in the log. I am _very_ worried about reversing the order of subdeployment nesting without a more complete dependency mechanism. If this is not stopping redeployment I would prefer to leave it till I can think about it more carefully. Have you seen what happens with your change with 1. the testsuite and 2. more complicated packaging such as ear containing sar containing ear containing rar? Thanks david jencks On 2002.03.18 09:48:08 -0500 Vesco Claudio wrote: Only for you :-) I have deployed bench.ear from testsuite and when I undeploy it I have this exception, ehm zipped :-) With call reordering I don't have exception :-) Claudio undeploy-exception.zip Patch.zip -Original Message- From: Vesco Claudio [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:27 PM To: 'David Jencks'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Ordering part 2 :-) I'll retest jboss without my patchs :-) please wait a moment :-) -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:24 PM To: [EMAIL PROTECTED] Subject:Re: [JBoss-dev] Ordering part 2 :-) Could you please show the exception you are seeing in the log. This will help me 1. understand without having to reproduce the problem what you are writing about. 2. If I do attempt to reproduce the problem, indicate to me that I have found the same problem you are working with. Have you seen this problem with any .ears from the testsuite? Thanks david jencks On 2002.03.18 08:35:57 -0500 Vesco Claudio wrote: If you try to make the deploy of a ear, then you make the undeploy and therefore you make the deploy of the same one ear, comes written in log one exception. In this moment, I don't have the possibility to give you a better example, but I think you can reproduce
[JBoss-dev] User TX bug
Hi alls! I think we have a little bug in server/src/main/org/jboss/tm/usertx/server/UserTransactionSessionImpl.ja va which I have triggered when I try to control user transaction by jython :-) In begin method there is a tm.suspend but in commit nor rollback there is no tm.resume. If there is no problems I'll patch it. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] User TX bug
Ahem, I have commited the change :-) -Original Message- From: marc fleury [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 2:15 PM To: Vesco Claudio; Jboss Dev (Posta elettronica) Subject: RE: [JBoss-dev] User TX bug yes we should resume, put it as a bug through sourceforge and put the patch when you can marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Vesco |Claudio |Sent: Wednesday, March 13, 2002 2:00 AM |To: Jboss Dev (Posta elettronica) |Subject: [JBoss-dev] User TX bug | | |Hi alls! | |I think we have a little bug in |server/src/main/org/jboss/tm/usertx/server/UserTransactionSessionImpl .ja |va which I have triggered when I try to control user transaction by |jython :-) | |In begin method there is a tm.suspend but in commit nor rollback there |is no tm.resume. | |If there is no problems I'll patch it. | | Claudio | |___ |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] [PATCH] Cannot compile Jetty Plugin in HEAD
I have compiled jetty plugin with JVM Sun 1.3.1 but I have the same
problem :-(
The patch resolves the problem...
java -version
java version 1.3.1
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Claudio
-Original Message-
From: Julian Gosnell [SMTP:[EMAIL PROTECTED]]
Sent: Friday, February 01, 2002 2:26 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] [PATCH] Cannot compile Jetty Plugin in
HEAD
I've just been told that the Sun 1.3 JVM ignores the
sar on the classpath whereas the 1.3.1 is quite happy
just to treat it as another jar.
I shall try to figure out a better way around this
this evening.
Sorry to break your build, guys.
If you can't wait, get a 1.3.1 JVM down now !
Jules
--- Patrick Mau [EMAIL PROTECTED] wrote: Hallo
everyone,
I'm still unable to build JBoss 3 and I have a
temporary
workaround for Jetty's build.xml. This is not a fix.
I'm just
wondering whats wrong with the
jbossha-httpsession.sar
file.
Error:
compile-classes:
[javac] Compiling 328 source files to
/usr/src/jboss/jboss-all/plugins/jetty/output/classes
[javac]
/usr/src/jboss/jboss-all/plugins/jetty/src/main/org/jboss/jetty/sessio
n/ClusteredHttpSessionData.java:20:
cannot resolve symbol
[javac] symbol : class SerializableHttpSession
[javac] location: package interfaces
[javac] import
org.jboss.ha.httpsession.interfaces.SerializableHttpSession;
Patch:
--- build.xml.orig Fri Feb 1 12:36:41 2002
+++ build.xml Fri Feb 1 12:34:49 2002
@@ -177,7 +177,8 @@
property name=jboss.cluster.root
value=${project.root}/cluster/output/
property name=jboss.cluster.lib
value=${jboss.cluster.root}/lib/
path id=jboss.cluster.classpath
- pathelement
path=${jboss.cluster.lib}/jbossha-httpsession.sar/
+ pathelement
path=${jboss.cluster.root}/classes/
+!-- pathelement
path=${jboss.cluster.lib}/jbossha-httpsession.sar/
--
/path
!-- The combined dependent module classpath
--
cheers,
Patrick
PS: Sorry for the layout. I had some trouble with
the Web Forum.
_
View thread online:
http://main.jboss.org/thread.jsp?forum=66thread=7689
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
___
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] Is Monday still a good 2.4 freeze date
My patches to implement JCA deployment are applied? :-) -Original Message- From: Scott M Stark [SMTP:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 10:09 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Is Monday still a good 2.4 freeze date This is just a suprious exception that can easily be cleaned up. Its also just a feature freeze to create the 2.4 branch, not a 2.4 release build as Juha said. The first release on the 2.4 branch will be a beta. - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 15, 2001 12:20 AM Subject: RE: [JBoss-dev] Is Monday still a good 2.4 freeze date Hi, IMHO, the re-deployment problem (see below) should stop you making a new release. For my part, I will test/validate the new DTD validation option as some elements are still missing from jaws.dtd (cmp-field is not defined). I will take care of dtd corrections. Vincent. [Container Management Proxy] Destroyed [Default] javax.management.InstanceAlreadyExistsException: Management:container=bank/Account [Default] at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.ja va:134 ) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerI mpl.ja va: [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.jav a:388) [Default] [Default] at org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java :716) [Default] [Default] at org.jboss.ejb.ContainerFactory.createEntityContainer(ContainerFactory. java:7 00) [Default] [Default] at org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:5 99) [Default] [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:471) [Default] [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:366) [Default] [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) [Default] [Default] at java.lang.reflect.Method.invoke(Native Method) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:162 8) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:152 3) [Default] [Default] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489) [Default] [Default] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:4 67) [Default] [Default] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211) [Default] [Default] at java.lang.reflect.Method.invoke(Native Method) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:162 8) [Default] [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:152 3) [Default] [Default] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379) [Default] [Default] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217) [Default] [Default] at java.lang.Thread.run(Unknown Source) [Default] -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : vendredi 15 juin 2001 2:24 À : JBoss Dev Objet : [JBoss-dev] Is Monday still a good 2.4 freeze date Is Monday still a good 2.4 freeze date for the features that will go into the 2.4 release or is more time needed? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Castor in lib/ext and common classloader
Hi alls! Why there is castor-0.9.1 in lib/ext? This jar is added in the common classloader path and so when I try to deploy and redeploy my castor RAR module I have problems to reinitialize castor (reloading the new DB mapping). Another problems... Is it possible to separate the common classloader in common classloader (jboss-j2ee.jar,...) / \ / \ jboss server cl (jaws,...) applications classloader (tomcat or jetty and so on...) / \ web cl... ejb cl... Claudio -- -- PREVINET S.p.A. [EMAIL PROTECTED] -- Via Ferretto 1 ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: R: R: R: [JBoss-dev] CX + Castor
On Mon, May 07, 2001 at 05:39:30PM +0200, Vesco Claudio wrote: Problems: where is called org.opentools.minerva.connector.*ConnectionManager.enlistExistingConnect ion - I cant reuse an existing connection :-( The enlistExistingConnection method is part of the contract that will allow the same connection handle to participate in multiple transactions. This functionality is not currently implemented; it is on my to do list. What this means is that, for the moment, you must obtain a connection handle in the context of transaction in which you wish to use it. I think that this is a good practice in general anyway, but reusing a single connection handle is more convenient to code. javax.resource.spi.ManagedConnection.associateConnection never called :-) I cant share an already open connection :-( I'm not sure what you mean by this. Are you happy or sad about it? Can you describe the behaviour that you are seeing and then the behaviour that you would like to see? The 2 problems are correlated I think. My reference is the spec, in particular 6.11 Connection Association, but I must reread the spec public draft 2 (I only read pd1). I this moment I have another problem with jca-castor integration, when I have time, I analize better your to do list :-) - in these days I dont like to sleep too much :-) Claudio Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: R: R: R: [JBoss-dev] CX + Castor
Hi, I'm not sure I understand all of your description of your rule engine requirements but from what I do understand I think they can be handled by what I wrote, jbossrules. I would be interested in seeing a more detailed explanation of what you are trying to do and may be interested in implementing it as a jbossrules example. Hi and sorry for my english :-) The project for my society is now only in my head. I dont like too much JEOPS-approach of jbossrules. I want a better separation from entity ejb and jdo beans. If we use jdo, the rule system can be applied to a wide range of system (not only application server) and my collegues can work without too much troubles. I dont like too much jess (licency), but I can implementing a system evolving jeops. For now I have another problem, jca-castor integration, when I have resolved this problem then I'll dedicate time to a rule system. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: R: R: R: [JBoss-dev] CX + Castor
My english is better over time? :-))) I want a rule engine with jdo(castor)/jboss with session beans and not entity beans, but I can rethink this (with jeops/jbossrules) when I complete the implementation castor-jca. The problem is: a remote call to a session ejb can transport data which must be validated with a rule engine (I think). Only when the data is valid then I store in db. If I remember in your implementation the rules are triggered by access to db. Another problem is the triggering is jboss-specific (with interceptors), I want a more portable solution (but I like too much jboss to convert to another application server :-))) ). Thanks you, Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 3:01 PM To: [EMAIL PROTECTED] Subject: RE: R: R: R: [JBoss-dev] CX + Castor Hi, If I understand you correctly, you do not want a ejb/jboss integrated rule engine but rather a jdo/castor integrated rule engine? So whether or not your requirements could be met by jbossrules is irrelevant, since it is an ejb - rule engine integration you don't want to use it? Thanks david jencks On 2001.05.08 03:40:40 -0400 Vesco Claudio wrote: Hi, I'm not sure I understand all of your description of your rule engine requirements but from what I do understand I think they can be handled by what I wrote, jbossrules. I would be interested in seeing a more detailed explanation of what you are trying to do and may be interested in implementing it as a jbossrules example. Hi and sorry for my english :-) The project for my society is now only in my head. I dont like too much JEOPS-approach of jbossrules. I want a better separation from entity ejb and jdo beans. If we use jdo, the rule system can be applied to a wide range of system (not only application server) and my collegues can work without too much troubles. I dont like too much jess (licency), but I can implementing a system evolving jeops. For now I have another problem, jca-castor integration, when I have resolved this problem then I'll dedicate time to a rule system. Claudio ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: R: R: [JBoss-dev] CX + Castor
Problems: where is called org.opentools.minerva.connector.*ConnectionManager.enlistExistingConnect ion - I cant reuse an existing connection :-( javax.resource.spi.ManagedConnection.associateConnection never called :-) I cant share an already open connection :-( For the ps (about a rule system implemented in jboss). We have a system which is called with a remote call (a session bean), the call parameters are a record set which only if they are validated they are written in db. The system are independent of persistent, the records are jdo or not. With Castor we can have these objects persistent or not. When we need validate the records, we can use jess or another rule system. The only requirement is which the objects are Beans with property change events and we dont needed ejb objects (entity or session). Claudio -Messaggio originale- Da: Toby Allsopp [SMTP:[EMAIL PROTECTED]] Inviato: lunedì 7 maggio 2001 9.58 A:[EMAIL PROTECTED] Oggetto: Re: R: R: [JBoss-dev] CX + Castor Vesco Claudio wrote: Thank you for the commiting... I have some problems to integrating Castor with jboss (minerva problems?)... Now I can deploy and redeploy rar with classloader isolation: I can add table, remove table in the ejb part and I redeploy the rar and I see the new access to db by Castor, jboss is always up and running ;-) There is some problems with reelinsting the resources + and shared connections :-( I think this is a minerva problem. I see and I kill these problems today :-) I'm very interested to hear about any problems you have with JBossCX or Minerva. I can't quite tell from the above whether you've resolved the problems or not, but please describe them either way. Toby. Hi, Claudio PS: my society is oriented to use a jdo implementation for implementing a rule system. I know there is another project, jbossrule, but I dont like too much. I'm sure you'll be called upon to explain that comment! :-) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CX + Castor
Hi all! Sorry for my bad english :-) I have done a little patch to jbosscx (ZipFile close exception) and I have converted castor 0.9.2 to JCA architecture, now I can deploy and redeploy rar and ejbs using castor jdo resources... (I don't use contrib/castorjdo). Can I post the patches to this list? Claudio -- -- PREVINET S.p.A. [EMAIL PROTECTED] -- Via Ferretto 1 ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] CX + Castor
I have submitted the patch... I dont have a direct access to Internet (no cvs anonymous at work :-( ) and so I have made a diff -ru with a snapshot. There is anybody which like a castor jca? :-) Claudio -Messaggio originale- Da: David Jencks [SMTP:[EMAIL PROTECTED]] Inviato: venerdì 4 maggio 2001 15.35 A:[EMAIL PROTECTED] Oggetto: Re: [JBoss-dev] CX + Castor Hi, There is a sourceforge patch submittal page for jboss at http://sourceforge.net/tracker/?group_id=22866atid=376687 at least this works for me. This does seem to be hard to find at the moment! Have you fixed the can't undeploy and redeploy a rar problem? If so, thanks!! Again if so, this fixes bug 415516, please note this in your patch submittal. Thanks david jencks On 2001.05.04 09:01:11 -0400 Vesco Claudio wrote: Hi all! Sorry for my bad english :-) I have done a little patch to jbosscx (ZipFile close exception) and I have converted castor 0.9.2 to JCA architecture, now I can deploy and redeploy rar and ejbs using castor jdo resources... (I don't use contrib/castorjdo). Can I post the patches to this list? Claudio -- -- PREVINET S.p.A. [EMAIL PROTECTED] -- Via Ferretto 1 ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
