[JBoss-dev] [ jboss-Bugs-610531 ] JMSXGroupID Property unusable
Bugs item #610531, was opened at 2002-09-17 08:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610531&group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lars Klose (klosels) Assigned to: Nobody/Anonymous (nobody) Summary: JMSXGroupID Property unusable Initial Comment: In JBoss 3.0.2 handling of the "JMSXGroupID" property defined in the JMS spec is not correct: while org.jboss.mq.SpyConnectionMetaData.getJMSXPropertyNames returns "JMSXGroupID" as one of the available properties, using this String as the property name in a call to org.jboss.mq.SpyMessage.setStringProperty fails because in org.jboss.mq.SpyMessage.CheckPropertyName it will be checked against "JMSGroupId". Note the different spelling Id vs ID! -- >Comment By: Hiram Chirino (chirino) Date: 2002-09-17 22:32 Message: Logged In: YES user_id=175851 Valid.. Corrected in CVS HEAD, 3.2, and 3.0 branch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610531&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610907 ] Using JMS in MDB/container-managed TX
Bugs item #610907, was opened at 2002-09-17 20:28
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610907&group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using JMS in MDB/container-managed TX
Initial Comment:
I've gotten MDB to work correctly with rolling-back
the database when I call mdc.setRollbackOnly().
However, I don't know how to create a QueueSession/Sender
which will send its messages after the onMessage() method
exists.
I have bought the JBoss documentation, but it does not have
an example of this case specifically. I suspect (but do not know)
that JBoss does not support automatic QueueSession
commit after an MDB exits its onMessage method. Looking
at the source after a few hours has gotten me confused.
I suspect this is NOT supported, if it is supported,
please forgive this bug submission and point me in
the right direction. This _should_ be documented,
at least document how this is correctly done.
The JMS tutorial:
http://java.sun.com/products/jms/tutorial/
has several examples of Container-managed TX
for MDB, which don't seem to work in JBoss.
Does anyone have an example of this sending out messages:
public class MessageDrivenBean implements MessageListener {
// Container-managed transactions with Required
// transaction attribute
public void onMessage(...) {
try {
QueueConnection qc = qcf.createQueueConnection();
QueueSession qs = qc.createQueueSession(true, 0);
QueueSender qsend = qs.createQueueSender("queue/A");
TextMessage m = qs.createTextMessage();
m.setText("test");
qsend.send(m);
/*
qs.close(); // JMS javadoc says this rollbacks
// In any case, doesn't seem to work
*/
qc.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610907&group_id=22866
---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608202 ] EJBQL fails to compile
Bugs item #608202, was opened at 2002-09-12 15:30
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608202&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Cory Prowse (cosmic)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: EJBQL fails to compile
Initial Comment:
OS:
Linux (2.4 kernel)
JDK:
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition
(build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03,
mixed mode)
JBoss Release:
JBoss-3.0.2 CVSTag=JBoss_3_0_2
NOTE: I will try and cut out a test case but it may
take a few days (deadline). A workaround is to use
OBJECT() and get the field that way.
When I attempt the following EJBQL:
ejbSelectCargoValue
packet.interfaces.PacketEntityLocal
java.lang.String
[CDATA[SELECT c.value FROM PacketEntity p, IN
(p.cargoes) AS c WHERE p = ?1 AND c.name = ?2]]
I get the following exception:
org.jboss.deployment.DeploymentException: Error
compiling ejbql; - nested throwable:
(java.lang.IllegalStateException: Can not visit
multi-column path node. Should have been handled at a
higher level.)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.(JDBCEJBQLQuery.java:46)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCCommandFactory.createEJBQLQuery(JDBCCommandFactory.java:44)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCQueryManager.start(JDBCQueryManager.java:214)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.startStoreManager(JDBCStoreManager.java:463)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:369)
at
org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:198)
--
>Comment By: Cory Prowse (cosmic)
Date: 2002-09-18 13:20
Message:
Logged In: YES
user_id=32851
I'm not sure what you mean?
I don't think I mapped it to multiple columns, it has no CMR
associated with it.
--
Comment By: Dain Sundstrom (dsundstrom)
Date: 2002-09-17 06:02
Message:
Logged In: YES
user_id=251431
Did you provide a mapping for the value cmp field (to
multiple columns)?
--
Comment By: Cory Prowse (cosmic)
Date: 2002-09-13 11:05
Message:
Logged In: YES
user_id=32851
The Entity beans in question have the following structure:
Packet {
long: packetId
}
Cargo {
long: cargoId
String: name
Object: value
}
With a relationship of one to many (Packet contains many
cargoes).
The Packet also has two other relationships set up with two
other Entities but they are not currently used (the HQSQLDB
has two other Foreign Key columns within the Packet table as
well). I'm not sure if that could be the cause of the issue
though... just letting you know the full details.
I can post the excerpts from the ejb-jar.xml?
--
Comment By: Dain Sundstrom (dsundstrom)
Date: 2002-09-13 03:39
Message:
Logged In: YES
user_id=251431
What is the type of c.value? Is it a mapped dependent value
class?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608202&group_id=22866
---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-610897 ]
Change Notes item #610897, was opened at 2002-09-17 22:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=610897&group_id=22866 Category: None Group: v3.2 Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Comment: Added this boolean flag to standardjboss.xml and jboss.xml If set to true, ejbStore will only be called on transaction commit. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=610897&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-610896 ]
Change Notes item #610896, was opened at 2002-09-17 22:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=610896&group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Comment: Added this boolean flag to standardjboss.xml and jboss.xml If set to true, ejbStore will only be called on transaction commit. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=610896&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-610898 ]
Change Notes item #610898, was opened at 2002-09-17 22:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=610898&group_id=22866 Category: None Group: v4.0 Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Comment: Added this boolean flag to standardjboss.xml and jboss.xml If set to true, ejbStore will only be called on transaction commit. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=610898&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Problem with mbean dispatcher? jboss 4
There appears to be something very wrong with the generated mbean dispatcher, causing datasources not to deploy and most of the tests to fail. Apparently under some circumstances a method is invoked twice: 2002-09-17 19:42:31,111 INFO [org.jboss.deployment.SARDeployer] sar deployer, 1 java.lang.Exception: stack trace at org.jboss.deployment.SARDeployer.init(SARDeployer.java:106) at org_jboss_deployment_SARDeployer_Dispatcher.invoke(org_jboss_deployment_SARDeployer_Dispatcher.class) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:548) at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:177) at $Proxy13.init(Unknown Source) at org.jboss.deployment.XSLSubDeployer.init(XSLSubDeployer.java:237) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:692) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) followed a little later (after the called init method returns) with 2002-09-17 19:42:31,147 INFO [org.jboss.deployment.SARDeployer] sar deployer, 1 java.lang.Exception: stack trace at org.jboss.deployment.SARDeployer.init(SARDeployer.java:106) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org_jboss_deployment_SARDeployer_Dispatcher.invoke(org_jboss_deployment_SARDeployer_Dispatcher.class) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:548) at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:177) at $Proxy13.init(Unknown Source) at org.jboss.deployment.XSLSubDeployer.init(XSLSubDeployer.java:237) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:692) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624) Note that the first time the reflection stuff is not used and the second time it is. Other calls in this chain appear to go through the reflective stuff. david jencks --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD Matrix2) Testsuite Results: 18-September-2002
Number of tests run: 658 Successful tests: 355 Errors:284 Failures: 19 [time of test: 18 September 2002 0:50 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_jdk131_03 for the junit report of this test. - http://lubega.com/testarchive/sun_jdk131_03/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608720 ] J2EE EJB Compat with J2EE SDK Server
Bugs item #608720, was opened at 2002-09-13 13:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: Anthony Ikeda (akikeda) Assigned to: Dain Sundstrom (dsundstrom) Summary: J2EE EJB Compat with J2EE SDK Server Initial Comment: When running the build template supplied with the JBoss examples pack, the generated Home and remote interfaces have some compatibility problems when deploying the same ejb.jar on the Sun J2EE SDK server (problem with valid RMI-IIOP types). See the TestCase.txt contained in the jar file for more details. NOTE: This jar is only an archive of non-java files not a java executable. Anthony -- >Comment By: Anthony Ikeda (akikeda) Date: 2002-09-18 09:47 Message: Logged In: YES user_id=610611 Thanks Dain, I'll try out some of the other J2EE servers and see if the problem re-occurs. If it does I'll forward it to EJBDoclet bugs. :-) Regards, Anthony -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-18 09:39 Message: Logged In: YES user_id=251431 This is an XDoclet bug, so you will have to report it at the XDoclet site. I doubt they will fix it as every other vendor supports it and no one uses the Sun J2EE SDK. -- Comment By: Anthony Ikeda (akikeda) Date: 2002-09-18 09:39 Message: Logged In: YES user_id=610611 I had a similar problem with the entityPK.j file in version xdoclet 1.1.2. The datatypes it was using for the hashcode were primitives. Cheers, Anthony -- Comment By: Anthony Ikeda (akikeda) Date: 2002-09-18 09:34 Message: Logged In: YES user_id=610611 EJBDoclet is adding new variables (COMP_NAME and JNDI_NAME) to the home interface which J2EE SDK doesn't seem to like. Apparently they are not valid RMI-IIOP types? If I remove these fields after the ejb doclet generation and recreate the jar it works fine. To remove them from the actual ejbdoclet process, the: xdoclet.modules.ejb.home.resources.home.xdt file needs to be edited to prevent these variables to be added (unless there is an ejbdoclet attribute to prevent it?). Or is it a sun bug instead? Cheers, Anthony -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-18 07:25 Message: Logged In: YES user_id=251431 The Sun J2EE SDK server is not a test kit. They may have gotten the spec wrong. Then again we maybe we got it wrong. Anyway, what exactally is the SDK complaining about? Have you tried hacking the code by hand to see what you need to change to fix this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608720 ] J2EE EJB Compat with J2EE SDK Server
Bugs item #608720, was opened at 2002-09-12 22:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Anthony Ikeda (akikeda) Assigned to: Dain Sundstrom (dsundstrom) Summary: J2EE EJB Compat with J2EE SDK Server Initial Comment: When running the build template supplied with the JBoss examples pack, the generated Home and remote interfaces have some compatibility problems when deploying the same ejb.jar on the Sun J2EE SDK server (problem with valid RMI-IIOP types). See the TestCase.txt contained in the jar file for more details. NOTE: This jar is only an archive of non-java files not a java executable. Anthony -- >Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-17 18:39 Message: Logged In: YES user_id=251431 This is an XDoclet bug, so you will have to report it at the XDoclet site. I doubt they will fix it as every other vendor supports it and no one uses the Sun J2EE SDK. -- Comment By: Anthony Ikeda (akikeda) Date: 2002-09-17 18:39 Message: Logged In: YES user_id=610611 I had a similar problem with the entityPK.j file in version xdoclet 1.1.2. The datatypes it was using for the hashcode were primitives. Cheers, Anthony -- Comment By: Anthony Ikeda (akikeda) Date: 2002-09-17 18:34 Message: Logged In: YES user_id=610611 EJBDoclet is adding new variables (COMP_NAME and JNDI_NAME) to the home interface which J2EE SDK doesn't seem to like. Apparently they are not valid RMI-IIOP types? If I remove these fields after the ejb doclet generation and recreate the jar it works fine. To remove them from the actual ejbdoclet process, the: xdoclet.modules.ejb.home.resources.home.xdt file needs to be edited to prevent these variables to be added (unless there is an ejbdoclet attribute to prevent it?). Or is it a sun bug instead? Cheers, Anthony -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-17 16:25 Message: Logged In: YES user_id=251431 The Sun J2EE SDK server is not a test kit. They may have gotten the spec wrong. Then again we maybe we got it wrong. Anyway, what exactally is the SDK complaining about? Have you tried hacking the code by hand to see what you need to change to fix this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608720 ] J2EE EJB Compat with J2EE SDK Server
Bugs item #608720, was opened at 2002-09-13 13:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Anthony Ikeda (akikeda) Assigned to: Dain Sundstrom (dsundstrom) Summary: J2EE EJB Compat with J2EE SDK Server Initial Comment: When running the build template supplied with the JBoss examples pack, the generated Home and remote interfaces have some compatibility problems when deploying the same ejb.jar on the Sun J2EE SDK server (problem with valid RMI-IIOP types). See the TestCase.txt contained in the jar file for more details. NOTE: This jar is only an archive of non-java files not a java executable. Anthony -- >Comment By: Anthony Ikeda (akikeda) Date: 2002-09-18 09:39 Message: Logged In: YES user_id=610611 I had a similar problem with the entityPK.j file in version xdoclet 1.1.2. The datatypes it was using for the hashcode were primitives. Cheers, Anthony -- Comment By: Anthony Ikeda (akikeda) Date: 2002-09-18 09:34 Message: Logged In: YES user_id=610611 EJBDoclet is adding new variables (COMP_NAME and JNDI_NAME) to the home interface which J2EE SDK doesn't seem to like. Apparently they are not valid RMI-IIOP types? If I remove these fields after the ejb doclet generation and recreate the jar it works fine. To remove them from the actual ejbdoclet process, the: xdoclet.modules.ejb.home.resources.home.xdt file needs to be edited to prevent these variables to be added (unless there is an ejbdoclet attribute to prevent it?). Or is it a sun bug instead? Cheers, Anthony -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-18 07:25 Message: Logged In: YES user_id=251431 The Sun J2EE SDK server is not a test kit. They may have gotten the spec wrong. Then again we maybe we got it wrong. Anyway, what exactally is the SDK complaining about? Have you tried hacking the code by hand to see what you need to change to fix this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-606812 ] Table not removed from db on undeploy
Bugs item #606812, was opened at 2002-09-09 11:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606812&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: Works For Me Priority: 5 Submitted By: Da C (dacu) Assigned to: Dain Sundstrom (dsundstrom) Summary: Table not removed from db on undeploy Initial Comment: Hi, I think there is a bug when undeploying a CMP entity bean that has relations. JBoss v3.0.2 Windows 2000 Pro JDK 1.3 Xdoclet for code generation On a test project, I have two CMP entity beans: Product and Order. I have defined a relation 1 to many between Order and Product. I used @jboss:relation tag with xdoclet, and the relation has also a constraint (fk_constraint=true). My Database is MS SQL Server 2000. Everything is generated correcty, but on undeploy, the Order table is not removed from Db. for ProductBean, the relation is defined as * @ejb:interface-method view-type="local" * @ejb:relation * name="product-order" * role-name="many-products-in-one-order" * * @jboss:relation * related-pk-field="id" * fk-column="OrderId" * fk-constraint="true" * */ public abstract inventory.interfaces.OrderEntityLocal getOrder(); for OrderBean, the relation is defined as * @ejb:interface-method view-type="local" * @ejb:relation * name="product-order" * role-name="one-order-has-many-products" * */ public abstract Set getOrderProducts(); This bug doesn't happen when I don't have a relation. Dan -- >Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-17 18:37 Message: Logged In: YES user_id=251431 When you increase the log leve to DEBUG do you see a DROP TABLE statement executed? Do you get a DEBUG message "Could not drop table OrderEntity"? If you execute DROP TABLE OrderEntity by hand will sql server actually drop the table? My guess is sql server won't drop the table because of a key constraint. Anyway I think this is a SQL Server issue that there is nothing we can do about. -- Comment By: Da C (dacu) Date: 2002-09-17 18:09 Message: Logged In: YES user_id=608507 I've checked teh generated files jaws.xml and jbosscmp- jdbc.xml. In both the remove-table attribute is set to true, so I think it's a jboss issue. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-16 15:05 Message: Logged In: YES user_id=251431 I assume that this is an XDoclet generation problem. If it is not reopen this bug. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-12 12:36 Message: Logged In: YES user_id=251431 Check the generated jbosscmp-jdbc.xml file. Does it have remove-table set to true. The current release of XDoclet incorrectly generates a jaws.xml file with remote-table set to true and jaws.xml is no longer used. I suggest you upgrade to XDoclet CVS head, or you write the jbosscmp-jdbc.xml file by hand. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606812&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608720 ] J2EE EJB Compat with J2EE SDK Server
Bugs item #608720, was opened at 2002-09-13 13:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Anthony Ikeda (akikeda) Assigned to: Dain Sundstrom (dsundstrom) Summary: J2EE EJB Compat with J2EE SDK Server Initial Comment: When running the build template supplied with the JBoss examples pack, the generated Home and remote interfaces have some compatibility problems when deploying the same ejb.jar on the Sun J2EE SDK server (problem with valid RMI-IIOP types). See the TestCase.txt contained in the jar file for more details. NOTE: This jar is only an archive of non-java files not a java executable. Anthony -- >Comment By: Anthony Ikeda (akikeda) Date: 2002-09-18 09:34 Message: Logged In: YES user_id=610611 EJBDoclet is adding new variables (COMP_NAME and JNDI_NAME) to the home interface which J2EE SDK doesn't seem to like. Apparently they are not valid RMI-IIOP types? If I remove these fields after the ejb doclet generation and recreate the jar it works fine. To remove them from the actual ejbdoclet process, the: xdoclet.modules.ejb.home.resources.home.xdt file needs to be edited to prevent these variables to be added (unless there is an ejbdoclet attribute to prevent it?). Or is it a sun bug instead? Cheers, Anthony -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-18 07:25 Message: Logged In: YES user_id=251431 The Sun J2EE SDK server is not a test kit. They may have gotten the spec wrong. Then again we maybe we got it wrong. Anyway, what exactally is the SDK complaining about? Have you tried hacking the code by hand to see what you need to change to fix this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610843 ] Caching of JaasSecurityManager.DomainInf
Bugs item #610843, was opened at 2002-09-17 16:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610843&group_id=22866 Category: JBossSX Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Timo Warns (timow) >Assigned to: Scott M Stark (starksm) Summary: Caching of JaasSecurityManager.DomainInf Initial Comment: We had problems with JaasSecurityManager. Sometimes it returned wrong values for "isUserInRole". Here is what we believe causes the problem: JaasSecurityManager uses (as default) TimedCachePolicy.get(Object) as method to access cached JaasSecurityManager.DomainInfo entries. TimedCachePolicy.get(Object) checks whether entries have expired and tries to refresh them if this is the case. If refreshing fails, the entry will be removed and "null" will be returned. The problem is that DomainInfo is not able to refresh (refresh() just returns "false"). Thus if a DomainInfo is expired and JaasSecurityManager.doesUserHaveRole(...) is called, it will return "false", even if "true" would be correct. Sorry, if we misunderstood anything! -- >Comment By: Scott M Stark (starksm) Date: 2002-09-17 16:21 Message: Logged In: YES user_id=175228 You are looking at out of date code. Since 3.0.1 only authentication requests will flush the cache and therefore roles are always consistent with the authenticated user. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610843&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610843 ] Caching of JaasSecurityManager.DomainInf
Bugs item #610843, was opened at 2002-09-18 01:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610843&group_id=22866 Category: JBossSX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Timo Warns (timow) Assigned to: Nobody/Anonymous (nobody) Summary: Caching of JaasSecurityManager.DomainInf Initial Comment: We had problems with JaasSecurityManager. Sometimes it returned wrong values for "isUserInRole". Here is what we believe causes the problem: JaasSecurityManager uses (as default) TimedCachePolicy.get(Object) as method to access cached JaasSecurityManager.DomainInfo entries. TimedCachePolicy.get(Object) checks whether entries have expired and tries to refresh them if this is the case. If refreshing fails, the entry will be removed and "null" will be returned. The problem is that DomainInfo is not able to refresh (refresh() just returns "false"). Thus if a DomainInfo is expired and JaasSecurityManager.doesUserHaveRole(...) is called, it will return "false", even if "true" would be correct. Sorry, if we misunderstood anything! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610843&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-606812 ] Table not removed from db on undeploy
Bugs item #606812, was opened at 2002-09-09 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606812&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Da C (dacu) Assigned to: Dain Sundstrom (dsundstrom) Summary: Table not removed from db on undeploy Initial Comment: Hi, I think there is a bug when undeploying a CMP entity bean that has relations. JBoss v3.0.2 Windows 2000 Pro JDK 1.3 Xdoclet for code generation On a test project, I have two CMP entity beans: Product and Order. I have defined a relation 1 to many between Order and Product. I used @jboss:relation tag with xdoclet, and the relation has also a constraint (fk_constraint=true). My Database is MS SQL Server 2000. Everything is generated correcty, but on undeploy, the Order table is not removed from Db. for ProductBean, the relation is defined as * @ejb:interface-method view-type="local" * @ejb:relation * name="product-order" * role-name="many-products-in-one-order" * * @jboss:relation * related-pk-field="id" * fk-column="OrderId" * fk-constraint="true" * */ public abstract inventory.interfaces.OrderEntityLocal getOrder(); for OrderBean, the relation is defined as * @ejb:interface-method view-type="local" * @ejb:relation * name="product-order" * role-name="one-order-has-many-products" * */ public abstract Set getOrderProducts(); This bug doesn't happen when I don't have a relation. Dan -- >Comment By: Da C (dacu) Date: 2002-09-17 23:09 Message: Logged In: YES user_id=608507 I've checked teh generated files jaws.xml and jbosscmp- jdbc.xml. In both the remove-table attribute is set to true, so I think it's a jboss issue. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-16 20:05 Message: Logged In: YES user_id=251431 I assume that this is an XDoclet generation problem. If it is not reopen this bug. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-12 17:36 Message: Logged In: YES user_id=251431 Check the generated jbosscmp-jdbc.xml file. Does it have remove-table set to true. The current release of XDoclet incorrectly generates a jaws.xml file with remote-table set to true and jaws.xml is no longer used. I suggest you upgrade to XDoclet CVS head, or you write the jbosscmp-jdbc.xml file by hand. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606812&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-606812 ] Table not removed from db on undeploy
Bugs item #606812, was opened at 2002-09-09 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606812&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Da C (dacu) Assigned to: Dain Sundstrom (dsundstrom) Summary: Table not removed from db on undeploy Initial Comment: Hi, I think there is a bug when undeploying a CMP entity bean that has relations. JBoss v3.0.2 Windows 2000 Pro JDK 1.3 Xdoclet for code generation On a test project, I have two CMP entity beans: Product and Order. I have defined a relation 1 to many between Order and Product. I used @jboss:relation tag with xdoclet, and the relation has also a constraint (fk_constraint=true). My Database is MS SQL Server 2000. Everything is generated correcty, but on undeploy, the Order table is not removed from Db. for ProductBean, the relation is defined as * @ejb:interface-method view-type="local" * @ejb:relation * name="product-order" * role-name="many-products-in-one-order" * * @jboss:relation * related-pk-field="id" * fk-column="OrderId" * fk-constraint="true" * */ public abstract inventory.interfaces.OrderEntityLocal getOrder(); for OrderBean, the relation is defined as * @ejb:interface-method view-type="local" * @ejb:relation * name="product-order" * role-name="one-order-has-many-products" * */ public abstract Set getOrderProducts(); This bug doesn't happen when I don't have a relation. Dan -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-16 20:05 Message: Logged In: YES user_id=251431 I assume that this is an XDoclet generation problem. If it is not reopen this bug. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-12 17:36 Message: Logged In: YES user_id=251431 Check the generated jbosscmp-jdbc.xml file. Does it have remove-table set to true. The current release of XDoclet incorrectly generates a jaws.xml file with remote-table set to true and jaws.xml is no longer used. I suggest you upgrade to XDoclet CVS head, or you write the jbosscmp-jdbc.xml file by hand. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=606812&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Thinlet and the JBoss Console GUI?
Has anyone looked into Thinlet (http://www.thinlet.com) as a possible widget set for a GUI console? Looks promising... fast... but I haven't looked into it very deeply. --jason --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608798 ] BIT/boolean mapping
Bugs item #608798, was opened at 2002-09-13 03:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608798&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jan Stolze (jstolze) Assigned to: Dain Sundstrom (dsundstrom) Summary: BIT/boolean mapping Initial Comment: The Java field boolean is not mapped to the correct SQL counterpart, which is BIT. Currently the boolean field is mapped to CHAR this is not conform the JDBC spec. -- Comment By: Jan Stolze (jstolze) Date: 2002-09-17 00:55 Message: Logged In: YES user_id=610703 I have discovered the source of my problem, in the EJB-deployment descriptor the data-type mapping was set to PostgreSQL instead of Microsoft SQL Server. -- Comment By: Jan Stolze (jstolze) Date: 2002-09-17 00:54 Message: Logged In: YES user_id=610703 I have discovered the source of my problem, in the EJB-deployment descriptor the data-type mapping was set to PostgreSQL instead of Microsoft SQL Server. -- Comment By: Jan Stolze (jstolze) Date: 2002-09-17 00:42 Message: Logged In: YES user_id=610703 I have discovered the source of my problem, in the EJB-deployment descriptor the data-type mapping was set to PostgreSQL instead of Microsoft SQL Server. -- Comment By: Jan Stolze (jstolze) Date: 2002-09-16 00:39 Message: Logged In: YES user_id=610703 Microsoft SQL Server 2000. I'm using the JDBC driver from Microsoft -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-13 11:19 Message: Logged In: YES user_id=251431 What database? Each database has a custom mapping. It does not matter what the JDBC spec says as no one follows it. We just try to find out what works. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608798&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608720 ] J2EE EJB Compat with J2EE SDK Server
Bugs item #608720, was opened at 2002-09-12 22:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Anthony Ikeda (akikeda) >Assigned to: Dain Sundstrom (dsundstrom) Summary: J2EE EJB Compat with J2EE SDK Server Initial Comment: When running the build template supplied with the JBoss examples pack, the generated Home and remote interfaces have some compatibility problems when deploying the same ejb.jar on the Sun J2EE SDK server (problem with valid RMI-IIOP types). See the TestCase.txt contained in the jar file for more details. NOTE: This jar is only an archive of non-java files not a java executable. Anthony -- >Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-17 16:25 Message: Logged In: YES user_id=251431 The Sun J2EE SDK server is not a test kit. They may have gotten the spec wrong. Then again we maybe we got it wrong. Anyway, what exactally is the SDK complaining about? Have you tried hacking the code by hand to see what you need to change to fix this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608720&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-609247 ] read-only messes up commit-option D
Bugs item #609247, was opened at 2002-09-14 07:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=609247&group_id=22866 Category: JBossServer >Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Martin Vilcans (marvil) >Assigned to: Bill Burke (patriot1burke) Summary: read-only messes up commit-option D Initial Comment: Commit option D does not work properly on entity beans that are declared as true in jboss.xml. The beans are reloaded every time they are used, instead of only by the interval that is declared in . Removing read-only from the bean makes option D work as expected. We had this problem with BMP beans, but the same problem appears on CMP beans. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=609247&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-595672 ] Deserialization broken in JBoss 3.01
Bugs item #595672, was opened at 2002-08-15 13:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=595672&group_id=22866 Category: JBossCMP >Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Boris Tamarkin (upss) Assigned to: Dain Sundstrom (dsundstrom) Summary: Deserialization broken in JBoss 3.01 Initial Comment: Win2000 operating system MySQL or MS SQLServer 2000 databases mapping in standardjbosscmp-jdbc.xml (same as in 3.0) for mySQL java.lang.Object JAVA_OBJECT LONGBLOB java.lang.Object JAVA_OBJECT IMAGE Repeat scenario Having CMP2 entity bean with one Object atribute. Call setObject works fine and store as a Blob in database. When trying to retreive after, failure happens. Stacktrace attached below *Notes: 1. Serialization and deserialization doing only with 3.01 version of JBoss 2. Not trying to deserealize old blobs (I am aware of it can be not supported and compatible with earlier version of JBoss) 3. This functionality and same code works fine with previous JBoss 3.0 version, but it is broken in 3.01. Thanks Stacktrace * 10:51:02,738 ERROR [LogInterceptor] TransactionRolledbackLocalException, causedB y: java.sql.SQLException: Unable to load to deserialize result: java.io.StreamCorru ptedException: invalid stream header at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.convertByteArra yToObject(JDBC Util.java:612) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.getResult (JDBCUtil.java:311) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMP FieldBridge.load ArgumentResults (JDBCAbstractCMPFieldBridge.java:350) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMP FieldBridge.load InstanceResults(JDBCAbstractCMPFieldBridge.java:304) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityComman d.execute(JDBCLoad EntityCommand.java:142) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityComman d.execute(JDBCLoad EntityCommand.java:62) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.load Entity(JDBCStoreM anager.java:572) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntit y(CMPPersistence Manager.java:410) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.load Entity(CachedConnectionInterceptor.java:353) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv oke(EntityS ynchronizationInterceptor.java:262) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invo ke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke (EntityInstance Interceptor.java:152) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke (EntityLockIntercep tor.java:107) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke (EntityCreation Interceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInte rceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxIntercep torCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:6 0) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor. java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:203) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:493) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv oke(BaseLoca lContainerInvoker.java:301) at org.jboss.ejb.plugins.local.EntityProxy.invoke (EntityProxy.java:38) at $Proxy161.getKeyValue(Unknown Source) at com.rendition.MyEJB.retrieveKey (MyEJB.java:155) ** -- >Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-17 16:08 Message: Logged In: YES user_id=251431 I spend all day testing this and have determined the following: Value classes in 3.0.0 were really broken. You can not have a field of type java.lang.Object and get the value back out. If you have a field of some custom type (like my.custom.ValueClass), it will work until you redeploy your applcation and then you get class cast exceptions because of a classloader conflict. Value classes work perfectly in 3.0.2 if the field was stored using 3.0.2. If it was stored with 3.0.0, it will work the first time you deploy, but you will get a class cast exception on redeploy. This is because 3.0.0 stored a java.rmi.MarshalledObject, which doesn't respect classloaders, and 3.0.1+ stores a MarshalledValue, which uses classloaders correctly. To make a long story short, there is nothing more we can do. Hopefully this will be the last data incompatiblity we have, but there is no guarantee. I suggest you try to find a way to store you values in a more portable way in the database, such as an xml string. -
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 17-September-2002
Number of tests run: 932
Successful tests: 915
Errors:11
Failures: 6
[time of test: 17 September 2002 13:12 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Sun and Jboss
The problem is not has Sun considers JBoss for-profit because of the association with The JBoss Group. The problem is Sun won't let The JBoss Group purchase access to the TDK like any other company. The won't give it to JBoss and they won't let The JBoss Group buy it, so they effectively block opensource from J2EE on a technicality. Shame on Sun. -dain Jules Gosnell wrote: > AFAIK you are right. > > The license is "free". > > Is Linux somehow not "free" because RedHat sells, distros, support & > consultancy on the back of it ? > > Jules > > > > > Randahl Fink Isaksen wrote: > >> Hmmm... I thought only the JBoss Group services were a for-profit >> project, whereas the JBoss open source server was a non-profit project. >> But maybe I am wrong in this distinction? >> >> >> Randahl >> >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]] On Behalf Of >> [EMAIL PROTECTED] >> Sent: 17. september 2002 10:34 >> To: [EMAIL PROTECTED] >> Subject: [JBoss-dev] Sun and Jboss >> >> http://java.sun.com/features/2002/09/opn_src_cooper.html >> TH folowing is from a interview with Danese Cooper posted on >> java.sun.com >> >> Question: >> JBoss Compatibility >> In a recent survey, a lot of developers want to know when Sun will >> allow JBoss to be branded as compatible with Java technology. >> Answer: >> Yeah, that's a really tough situation. JBoss is an open source project >> that wants to say they are compatible with J2EE, but they are also a >> for-profit project, so they can't apply for zero-cost access to the TCKs >> under the new rules. Recently JBoss launched its own certification >> program, which is interesting. Open source wisdom says that it's really >> hard to maintain a fork. It will be interesting to see how they do. I'd >> really like to see Sun and JBoss work together to find a solution to the >> problem. They got great coverage at the 2002 JavaOneSM conference -- >> several awards. It's a very popular effort. --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Sun and Jboss
AFAIK you are right. The license is "free". Is Linux somehow not "free" because RedHat sells, distros, support & consultancy on the back of it ? Jules Randahl Fink Isaksen wrote: > Hmmm... I thought only the JBoss Group services were a for-profit > project, whereas the JBoss open source server was a non-profit project. > But maybe I am wrong in this distinction? > > > Randahl > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of > [EMAIL PROTECTED] > Sent: 17. september 2002 10:34 > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Sun and Jboss > > http://java.sun.com/features/2002/09/opn_src_cooper.html > TH folowing is from a interview with Danese Cooper posted on > java.sun.com > > Question: > JBoss Compatibility > In a recent survey, a lot of developers want to know when Sun will > allow JBoss to be branded as compatible with Java technology. > > Answer: > Yeah, that's a really tough situation. JBoss is an open source project > that wants to say they are compatible with J2EE, but they are also a > for-profit project, so they can't apply for zero-cost access to the TCKs > under the new rules. Recently JBoss launched its own certification > program, which is interesting. Open source wisdom says that it's really > hard to maintain a fork. It will be interesting to see how they do. I'd > really like to see Sun and JBoss work together to find a solution to the > problem. They got great coverage at the 2002 JavaOneSM conference -- > several awards. It's a very popular effort. > > > > __ > The NEW Netscape 7.0 browser is now available. Upgrade now! > http://channels.netscape.com/ns/browsers/download.jsp > > Get your own FREE, personal Netscape Mail account today at > http://webmail.netscape.com/ > > > --- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [jboss-cvs] jmx/src/main/org/jboss/mx/persistenceObjectStreamPersistenceManager.java OsPersistMgr.java
I use jEdit 4.0 final with the latest JavaStyle plugin from the plugin
central. Seems to work (and the JavaStyle plugin has gone a long way since
the last version I used).
I entered the parameters in the plugin GUI by hand. I assume it stores the
config somewhere I'll check if I can find the file, can email it to you.
Donät know about ANT integration, there was some work on it once but I
think it might have been dropped.
-- Juha
On Tue, 17 Sep 2002, Matt Munz wrote:
> Juha & group,
>
> I figured I missed a few i's and t's in there...
>
> Is this the JavaStyle plugin for JEdit? I can't seem to get it to work at
> the moment. But assuming I do, is there profile / rule-set for the jboss
> coding conventions I can import, or do I need to enter them in by hand? Are
> there similar profiles available for any of the other source code formatters
> out there?
>
> I've been thinking about using a formatter, especially one that I can
> integrate into my build processes (ANT), and optionally Eclipse -- I'd
> appreciate any pointers.
>
> - Matt
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Juha
> Lindfors
> Sent: Tuesday, September 17, 2002 1:25 PM
> To: [EMAIL PROTECTED]
> Subject: [jboss-cvs] jmx/src/main/org/jboss/mx/persistence
> ObjectStreamPersistenceManager.java OsPersistMgr.java
>
>
> User: juhalindfors
> Date: 02/09/17 10:25:19
>
> Added: src/main/org/jboss/mx/persistence
> ObjectStreamPersistenceManager.java
> Removed: src/main/org/jboss/mx/persistence OsPersistMgr.java
> Log:
> OsPersistMgr renamed to ObjectStreamPersistenceManager
>
> Code run through JavaStyle to enforce JBoss coding style.
>
> Revision ChangesPath
> 1.1
> jmx/src/main/org/jboss/mx/persistence/ObjectStreamPersistenceManager.java
>
> Index: ObjectStreamPersistenceManager.java
> ===
> package org.jboss.mx.persistence;
>
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.ObjectInputStream;
> import java.io.ObjectOutputStream;
> import javax.management.Attribute;
> import javax.management.AttributeList;
> import javax.management.Descriptor;
> import javax.management.MBeanAttributeInfo;
> import javax.management.MBeanException;
> import javax.management.MBeanInfo;
> import javax.management.modelmbean.ModelMBeanAttributeInfo;
> import javax.management.modelmbean.ModelMBeanInfo;
> import javax.management.modelmbean.ModelMBeanInfoSupport;
> import org.apache.log4j.Logger;
> import org.jboss.mx.modelmbean.ModelMBeanConstants;
> import org.jboss.mx.modelmbean.ModelMBeanInvoker;
> import org.jboss.mx.persistence.PersistenceManager;
>
> /**
>* Object Stream Persistence Manager.
>*
>* Persists the MBean to the file system using an Object Stream.
>* Includes code based on examples in Juha's JMX Book.
>*
>* Object Streams written to disk are admittedly lacking in the area of
> "long-term", "portable",
>* or "human-readable" persistence. They are fairly straightforward,
> however.
>* Primarily, this class is useful for demonstration and "quick & dirty"
> persistence.
>*
>* @todo currently metadata as well as data is stored. only data
> needs to be stored.
>* @authorMatt Munz
>*/
> public class ObjectStreamPersistenceManager
> extends Object
> implements PersistenceManager
> {
> protected boolean fIsLoading;
> protected Logger fLogger;
>
>
> // Constructors --
>
> public ObjectStreamPersistenceManager()
> {
> super();
> }
>
>
> // Public
>
> /**
> * deserializes state from the object input stream
> *
> * @param mbean
> * @param metadata
> * @exception MBeanException
> */
> public void load(ModelMBeanInvoker mbean, MBeanInfo metadata) throws
> MBeanException
> {
> logger().debug("FilePersist.load; metadata: " + metadata);
> // based on jmx book
> if (metadata == null)
> {
>return;
> }
> Descriptor d = ((ModelMBeanInfo)metadata).getMBeanDescriptor();
> String dir =
> (String)d.getFieldValue(ModelMBeanConstants.PERSIST_LOCATION);
> String file =
> (String)d.getFieldValue(ModelMBeanConstants.PERSIST_NAME);
> if (file == null)
> {
>return;
> }
> try
> {
>File f = new File(dir, file);
>FileInputStream fis = new FileInputStream(f);
>ObjectInputStream ois = new ObjectInputStream(fis);
>metadata = (ModelMBeanInfoSupport)ois.readObject();
>logger().info("metadata deserialized");
>
[JBoss-dev] RE: [jboss-cvs] jmx/src/main/org/jboss/mx/persistence ObjectStreamPersistenceManager.java OsPersistMgr.java
Juha & group,
I figured I missed a few i's and t's in there...
Is this the JavaStyle plugin for JEdit? I can't seem to get it to work at
the moment. But assuming I do, is there profile / rule-set for the jboss
coding conventions I can import, or do I need to enter them in by hand? Are
there similar profiles available for any of the other source code formatters
out there?
I've been thinking about using a formatter, especially one that I can
integrate into my build processes (ANT), and optionally Eclipse -- I'd
appreciate any pointers.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Juha
Lindfors
Sent: Tuesday, September 17, 2002 1:25 PM
To: [EMAIL PROTECTED]
Subject: [jboss-cvs] jmx/src/main/org/jboss/mx/persistence
ObjectStreamPersistenceManager.java OsPersistMgr.java
User: juhalindfors
Date: 02/09/17 10:25:19
Added: src/main/org/jboss/mx/persistence
ObjectStreamPersistenceManager.java
Removed: src/main/org/jboss/mx/persistence OsPersistMgr.java
Log:
OsPersistMgr renamed to ObjectStreamPersistenceManager
Code run through JavaStyle to enforce JBoss coding style.
Revision ChangesPath
1.1
jmx/src/main/org/jboss/mx/persistence/ObjectStreamPersistenceManager.java
Index: ObjectStreamPersistenceManager.java
===
package org.jboss.mx.persistence;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import javax.management.Attribute;
import javax.management.AttributeList;
import javax.management.Descriptor;
import javax.management.MBeanAttributeInfo;
import javax.management.MBeanException;
import javax.management.MBeanInfo;
import javax.management.modelmbean.ModelMBeanAttributeInfo;
import javax.management.modelmbean.ModelMBeanInfo;
import javax.management.modelmbean.ModelMBeanInfoSupport;
import org.apache.log4j.Logger;
import org.jboss.mx.modelmbean.ModelMBeanConstants;
import org.jboss.mx.modelmbean.ModelMBeanInvoker;
import org.jboss.mx.persistence.PersistenceManager;
/**
* Object Stream Persistence Manager.
*
* Persists the MBean to the file system using an Object Stream.
* Includes code based on examples in Juha's JMX Book.
*
* Object Streams written to disk are admittedly lacking in the area of
"long-term", "portable",
* or "human-readable" persistence. They are fairly straightforward,
however.
* Primarily, this class is useful for demonstration and "quick & dirty"
persistence.
*
* @todo currently metadata as well as data is stored. only data
needs to be stored.
* @authorMatt Munz
*/
public class ObjectStreamPersistenceManager
extends Object
implements PersistenceManager
{
protected boolean fIsLoading;
protected Logger fLogger;
// Constructors --
public ObjectStreamPersistenceManager()
{
super();
}
// Public
/**
* deserializes state from the object input stream
*
* @param mbean
* @param metadata
* @exception MBeanException
*/
public void load(ModelMBeanInvoker mbean, MBeanInfo metadata) throws
MBeanException
{
logger().debug("FilePersist.load; metadata: " + metadata);
// based on jmx book
if (metadata == null)
{
return;
}
Descriptor d = ((ModelMBeanInfo)metadata).getMBeanDescriptor();
String dir =
(String)d.getFieldValue(ModelMBeanConstants.PERSIST_LOCATION);
String file =
(String)d.getFieldValue(ModelMBeanConstants.PERSIST_NAME);
if (file == null)
{
return;
}
try
{
File f = new File(dir, file);
FileInputStream fis = new FileInputStream(f);
ObjectInputStream ois = new ObjectInputStream(fis);
metadata = (ModelMBeanInfoSupport)ois.readObject();
logger().info("metadata deserialized");
loadFromMetadata(mbean, (ModelMBeanInfo)metadata);
}
catch (Exception e)
{
logger().error("Error loading MBean state", e);
}
// end from book
}
/**
* What we need to get here is 1) the persist location, and 2) the
entire contents of the mbean
* #2 contains the entire contents (state) of the model object, as well
as the meta data
* that the mbean provides.
* As such, serializing this (MBeanInfo) object (brute force) in effect
serializes the model as well.
*
* @param metadata
* @exception MBeanException
*/
public void store(MBeanInfo metadata) throws MBeanException
{
System.out.printl
Re: [JBoss-dev] "No security context set" in ejbCreate() of SFSB
Yes, the usage is inconsistent. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Peter Levart" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 17, 2002 8:14 AM Subject: [JBoss-dev] "No security context set" in ejbCreate() of SFSB > JBoss 3.0.2: > > This is related to Bug ID: 608807. > > The EJB 2.0 specification allows a call to SessionContext.getCallerPrincipal() > in the ejbCreate() method of the Statefull Session Bean. > > When called from a remote (not in the same VM) client, this throws > IllegalStateException: No security context set... > > The problem as I see it is that the > StatefulSessionInstanceInterceptor.invlokeHome() sets the context's principal > from the SecurityAssociation's principal. This is ok for in-VM calls since > the thread is the same. But for remote calls, the principal comes from the > Invocation. > > Ok, the SecurityInterceptor does associate the principal and credentials from > the Invocation to the current thread (SecurityAssociation), but it is called > after Instance interceptors (usualy). > > If I compare the StatefulSessionInstanceInterceptor.invlokeHome() to the > EntityInstanceInterceptor.invokeHome(), the later takes the principal from > the Invocation. Isn't the same behaviour desired for statefull beans as well? > > I also spoted the same (maybe wrong) usage in the > StatelessSessionInstanceInterceptor.invoke() method. > > I may not see the whole picture here, but it seems inconsistent. Isn't the > principal always packed into Invocation before it is passed to interceptors? > > I will file this as a bug if I get some kind of confirmation that I'm not > wrong here. > > > Regards, Peter > > > > --- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610008 ] Verifier too strict for 2.0 cmp 1.1 home
Bugs item #610008, was opened at 2002-09-16 09:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 Category: JBossServer Group: v3.2 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Christian Riege (lqd) Summary: Verifier too strict for 2.0 cmp 1.1 home Initial Comment: The verifier is validating 2.0 EJBs that use 1.1 cmp as EJB 1.1 beans. This fails when the home includes method forms from the EJB 2.0 spec, which should be allowed. See the current failures to deploy the org.jboss.test.testbean.test.BeanUnitTestCase testbean.jar in either 3.2 or main. -- >Comment By: Scott M Stark (starksm) Date: 2002-09-17 10:00 Message: Logged In: YES user_id=175228 The let's change the verifier error to a warning if a 2.0 DTD is seen and the entity bean is using cmp 1.1 -- Comment By: Christian Riege (lqd) Date: 2002-09-17 08:48 Message: Logged In: YES user_id=176671 CMP 1.x Entity Beans are not checked anymore when encountered in a 2.0 JAR file. This is also noted in the logging infrastructure, although on a DEBUG level (see org.jboss.ejb.EJBDeployer for more info on this). This is certainly not the most elegant solution but its the most viable workaround I can see ATM w/o opening up too many construction sites in the current code. The whole Verifier infrastructure will undergo a rewrite for JBoss 4.0; once that is ready and tested a backport into 3.x Branch should be possible w/o many problems. I just need a quiet weekend to get that done :). Stay tuned. Oh yeah, this is in HEAD and 3.2; does it make sense to bring this into 3.0, too? -- Comment By: Christian Riege (lqd) Date: 2002-09-17 08:09 Message: Logged In: YES user_id=176671 The current Verifier doesn't have a notion of different levels of Spec Violations (i.e. Warning/Error). This is on my TODO for the next generation of the Verifier. I think what I will do is a work-around in the current incarnation. EJB 1.1 Beans inside a 2.0 jar won't get verified at all and a warning message will be issued. -- Comment By: Scott M Stark (starksm) Date: 2002-09-17 07:42 Message: Logged In: YES user_id=175228 The let's change the verifier error to a warning if a 2.0 DTD is seen and the entity bean is using cmp 1.1 -- Comment By: Christian Riege (lqd) Date: 2002-09-17 01:56 Message: Logged In: YES user_id=176671 I will have a look at this but from my memory the current architecture of the Verifier doesn't allow for an easy fix for this -- it's either 2.0 or 1.1 all the way. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610552 ] PrefixDeploymentSorter and non-digit URL
Bugs item #610552, was opened at 2002-09-17 06:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610552&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: PrefixDeploymentSorter and non-digit URL Initial Comment: If using org.jboss.deployment.scanner.PrefixDeploymentSorter those files beginning with non-digit are deployed FIRST, not LAST as declared in comments inside jboss-service.xml. This is because private int getPrefixValue(URL url) returns -1 if no digital prefix exists. It should return Integer.MAX_VALUE or something. -- >Comment By: Larry Sanderson (lsanders) Date: 2002-09-17 09:08 Message: Logged In: YES user_id=379453 This was my bad - the original implementation of this was to deploy prefixed first (as all the comments indicate). Then it was agreed to change this to prefixed last. I changed the code, but not the docs. I'll check in new docs today. -- Comment By: Christian Riege (lqd) Date: 2002-09-17 07:35 Message: Logged In: YES user_id=176671 The question is if this is a bug in the "documentation" or in the "implementation" :). The JavaDoc comments in PrefixDeploymentSorter are misleading here, too as they state: "... If there is no leading digits, then they will compare as less than any name with leading digits." and a few lines further down: "Ex.these names are in ascending order: 001test.jar, 5test.rar, 5foo.jar, 120bar.jar, test.sar, crap.ear )" which contradicts the previous statement. Which one is the "correct" behaviour here? I would opt for the "deploy with no prefix first" strategy (as it is implemted ATM) and fix the comments in the .xml file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610552&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MarshalException for Remote Invocation (610392)
Tyrex has makes use of the OTS (jts corba stuff) and has a TransactionPropogationContext (TPC) which wraps the OTS propogation context. The OTS has XA resources as well as Xids that are externalizable. So yes this is done by the tyrex plugin specifically. It takes the TPC on an import and converts it to a Transaction. As well on the reverse takes a Transaction and coverts it to a TPC which can be serialized. The JBoss implementaion allows the TPC to be added to any marshalled invocation. So the capability to do distributed transactions is already in therejust not for the the default JBoss transaction manager. It actually uses a TransactionImpl as a TPC. Just FYI the change to the storage location for the Transaction in the MarshalledInvocation seems to work. I am currently able to do distributed transactions with the tyrex plugin under 3.0.1. I have not run the testsuite yet but will shortly. Thanks -=Brian On Tue, 2002-09-17 at 06:37, David Jencks wrote: > I haven't looked at the code, I've just been thinking about how to make the > jboss tm distributed. > > First, until the jboss tm is distributed, it seems to me that problems > invoking an ejb on another server from inside a tx using the jboss tm are > appropriate, since the tx can't be propagated. > > Using tyrex or the future enhanced jboss tm, I believe there has to be an > XAResource somewhere near the remote invoker or proxy that gets the tm to > produce an xid branch for the tx on the other server. IMO the Xid is what > should get serialized and sent over. I've been thinking that a client > interceptor would be the place for the XAResource. On the other side, > something needs to take the xid and create a transaction on the 2nd server, > associated with this xid. The "something" is implemented in jboss 4 in the > jca 1.5 support. > > WIth Tyrex, I imagine they must have code that does this stuff. Does the > tyrex integration code appear to be trying to do any of this? > > Thanks > david jencks > > > On 2002.09.17 03:18:15 -0400 Brian Towles wrote: > > Howdy all > > > > Repeating what be bug said.. (just for frame of reference) > > > > -- > > A Marshaling Exception is being thrown the remote > > invoker when any remote EJB function is called > > (inter-jboss). Even when using Tyrex as a transaction > > manager. > > > > This is being caused by the Transaction Implmentation > > being placed in the MarshalledInvocation's > > as_is_payload Map. This is preventing any remote > > invocation because the TransactionImpl for both jboss > > and tyrex are not serializable. > > > > For a remote invocation it is my understanding that > > only the TransactionPropogationContext (TPC) is what is > > needed to migrate the transaction for remote > > invocation. The TPC is being placed in the in the > > MarshaledInvocation correctly. > > -- > > > > Ive been hunting this one down for a while and I would like some advice > > on what a proper fix would be. > > > > Would simply putting it into the transient_payload keep things working > > internally? Theoretically it should then not be marshaled and the TPC > > should be the transaction propagation mechanism for remote. > > > > Right now I'm looking for a quick solution cause I have a deadline to > > meet. (don't we all). > > > > Any hints would help > > > > Thanks > > -=Brian > > > > > > > > > > > > > > > > --- > > Sponsored by: AMD - Your access to the experts on Hammer Technology! > > Open Source & Linux Developers, register now for the AMD Developer > > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > --- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610008 ] Verifier too strict for 2.0 cmp 1.1 home
Bugs item #610008, was opened at 2002-09-16 18:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 Category: JBossServer Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Christian Riege (lqd) Summary: Verifier too strict for 2.0 cmp 1.1 home Initial Comment: The verifier is validating 2.0 EJBs that use 1.1 cmp as EJB 1.1 beans. This fails when the home includes method forms from the EJB 2.0 spec, which should be allowed. See the current failures to deploy the org.jboss.test.testbean.test.BeanUnitTestCase testbean.jar in either 3.2 or main. -- >Comment By: Christian Riege (lqd) Date: 2002-09-17 17:48 Message: Logged In: YES user_id=176671 CMP 1.x Entity Beans are not checked anymore when encountered in a 2.0 JAR file. This is also noted in the logging infrastructure, although on a DEBUG level (see org.jboss.ejb.EJBDeployer for more info on this). This is certainly not the most elegant solution but its the most viable workaround I can see ATM w/o opening up too many construction sites in the current code. The whole Verifier infrastructure will undergo a rewrite for JBoss 4.0; once that is ready and tested a backport into 3.x Branch should be possible w/o many problems. I just need a quiet weekend to get that done :). Stay tuned. Oh yeah, this is in HEAD and 3.2; does it make sense to bring this into 3.0, too? -- Comment By: Christian Riege (lqd) Date: 2002-09-17 17:09 Message: Logged In: YES user_id=176671 The current Verifier doesn't have a notion of different levels of Spec Violations (i.e. Warning/Error). This is on my TODO for the next generation of the Verifier. I think what I will do is a work-around in the current incarnation. EJB 1.1 Beans inside a 2.0 jar won't get verified at all and a warning message will be issued. -- Comment By: Scott M Stark (starksm) Date: 2002-09-17 16:42 Message: Logged In: YES user_id=175228 The let's change the verifier error to a warning if a 2.0 DTD is seen and the entity bean is using cmp 1.1 -- Comment By: Christian Riege (lqd) Date: 2002-09-17 10:56 Message: Logged In: YES user_id=176671 I will have a look at this but from my memory the current architecture of the Verifier doesn't allow for an easy fix for this -- it's either 2.0 or 1.1 all the way. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] "No security context set" in ejbCreate() of SFSB
JBoss 3.0.2: This is related to Bug ID: 608807. The EJB 2.0 specification allows a call to SessionContext.getCallerPrincipal() in the ejbCreate() method of the Statefull Session Bean. When called from a remote (not in the same VM) client, this throws IllegalStateException: No security context set... The problem as I see it is that the StatefulSessionInstanceInterceptor.invlokeHome() sets the context's principal from the SecurityAssociation's principal. This is ok for in-VM calls since the thread is the same. But for remote calls, the principal comes from the Invocation. Ok, the SecurityInterceptor does associate the principal and credentials from the Invocation to the current thread (SecurityAssociation), but it is called after Instance interceptors (usualy). If I compare the StatefulSessionInstanceInterceptor.invlokeHome() to the EntityInstanceInterceptor.invokeHome(), the later takes the principal from the Invocation. Isn't the same behaviour desired for statefull beans as well? I also spoted the same (maybe wrong) usage in the StatelessSessionInstanceInterceptor.invoke() method. I may not see the whole picture here, but it seems inconsistent. Isn't the principal always packed into Invocation before it is passed to interceptors? I will file this as a bug if I get some kind of confirmation that I'm not wrong here. Regards, Peter --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Should modelmbean forward MBeanRegistration calls to managed resource?
OK, that's what I implemented. If we find that interceptors need to see these calls we can revisit the question. thanks david jencks On 2002.09.17 09:02:46 -0400 Adrian Brock wrote: > The question is not should but can? :-) > > The spec requires the MBeanServer to invoke the ModelMBean's > pre/post[De]Register. It is silent on whether the ModelMBean > forwards that to the "pojo". > > The pojo implementing the interface should be enough configuration > shouldn't it? > > Regards, > Adrian > > >From: David Jencks <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: jboss-dev <[EMAIL PROTECTED]> > >Subject: [JBoss-dev] Should modelmbean forward MBeanRegistration calls > to > >managed resource? > >Date: Tue, 17 Sep 2002 00:35:23 -0400 > > > >I think it's an oversight... shouldn't modelMbean forward the > >MBeanRegistration calls to the managed resource if that resource > implements > >MBeanRegistration? > > > >Our ServiceMBeanSupport subclasses need these calls to get the server > and > >their objectName. I've added this so subclasses can be xmbeans. Should > >this be configurable by descriptors? > > > >Thanks > >david jencks > > > > > >--- > >Sponsored by: AMD - Your access to the experts on Hammer Technology! > >Open Source & Linux Developers, register now for the AMD Developer > >Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > _ > Join the worlds largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > > --- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610008 ] Verifier too strict for 2.0 cmp 1.1 home
Bugs item #610008, was opened at 2002-09-16 18:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Christian Riege (lqd) Summary: Verifier too strict for 2.0 cmp 1.1 home Initial Comment: The verifier is validating 2.0 EJBs that use 1.1 cmp as EJB 1.1 beans. This fails when the home includes method forms from the EJB 2.0 spec, which should be allowed. See the current failures to deploy the org.jboss.test.testbean.test.BeanUnitTestCase testbean.jar in either 3.2 or main. -- >Comment By: Christian Riege (lqd) Date: 2002-09-17 17:09 Message: Logged In: YES user_id=176671 The current Verifier doesn't have a notion of different levels of Spec Violations (i.e. Warning/Error). This is on my TODO for the next generation of the Verifier. I think what I will do is a work-around in the current incarnation. EJB 1.1 Beans inside a 2.0 jar won't get verified at all and a warning message will be issued. -- Comment By: Scott M Stark (starksm) Date: 2002-09-17 16:42 Message: Logged In: YES user_id=175228 The let's change the verifier error to a warning if a 2.0 DTD is seen and the entity bean is using cmp 1.1 -- Comment By: Christian Riege (lqd) Date: 2002-09-17 10:56 Message: Logged In: YES user_id=176671 I will have a look at this but from my memory the current architecture of the Verifier doesn't allow for an easy fix for this -- it's either 2.0 or 1.1 all the way. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610008 ] Verifier too strict for 2.0 cmp 1.1 home
Bugs item #610008, was opened at 2002-09-16 09:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Christian Riege (lqd) Summary: Verifier too strict for 2.0 cmp 1.1 home Initial Comment: The verifier is validating 2.0 EJBs that use 1.1 cmp as EJB 1.1 beans. This fails when the home includes method forms from the EJB 2.0 spec, which should be allowed. See the current failures to deploy the org.jboss.test.testbean.test.BeanUnitTestCase testbean.jar in either 3.2 or main. -- >Comment By: Scott M Stark (starksm) Date: 2002-09-17 07:42 Message: Logged In: YES user_id=175228 The let's change the verifier error to a warning if a 2.0 DTD is seen and the entity bean is using cmp 1.1 -- Comment By: Christian Riege (lqd) Date: 2002-09-17 01:56 Message: Logged In: YES user_id=176671 I will have a look at this but from my memory the current architecture of the Verifier doesn't allow for an easy fix for this -- it's either 2.0 or 1.1 all the way. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610552 ] PrefixDeploymentSorter and non-digit URL
Bugs item #610552, was opened at 2002-09-17 15:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610552&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: PrefixDeploymentSorter and non-digit URL Initial Comment: If using org.jboss.deployment.scanner.PrefixDeploymentSorter those files beginning with non-digit are deployed FIRST, not LAST as declared in comments inside jboss-service.xml. This is because private int getPrefixValue(URL url) returns -1 if no digital prefix exists. It should return Integer.MAX_VALUE or something. -- >Comment By: Christian Riege (lqd) Date: 2002-09-17 16:35 Message: Logged In: YES user_id=176671 The question is if this is a bug in the "documentation" or in the "implementation" :). The JavaDoc comments in PrefixDeploymentSorter are misleading here, too as they state: "... If there is no leading digits, then they will compare as less than any name with leading digits." and a few lines further down: "Ex.these names are in ascending order: 001test.jar, 5test.rar, 5foo.jar, 120bar.jar, test.sar, crap.ear )" which contradicts the previous statement. Which one is the "correct" behaviour here? I would opt for the "deploy with no prefix first" strategy (as it is implemted ATM) and fix the comments in the .xml file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610552&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-609902 ] java.lang.LinkageError: loader ...
Bugs item #609902, was opened at 2002-09-16 15:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=609902&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: java.lang.LinkageError: loader ... Initial Comment: Assume some application (client) deployed into jboss uses EJBs deployed in another application (server). If client's interfaces declared as throwing some custom exception (in this case this exception has to be present in both client and server jars/wars/ears) a java.lang.LinkageError may occur when trying to invoke inside client methods of server's interface those throwing that custom exception: java.lang.LinkageError: loader constraints violated when linking xxx/xxx/Clazz class In my case the exception occurs after I re-deploy the client application. Only by restarting jboss it is possible to restore the normal functionality once the error is occured. I suppose this is because the custom exception class isn't loaded by a common classloader as all interface classes, return type classes etc. are. This problem doesn't appear in jboss 2.4.x. EJB spec allows custom exceptions so I think this is a bug, not a feature. -- >Comment By: Alexei Yudichev (sflexus) Date: 2002-09-17 16:55 Message: Logged In: YES user_id=345880 Allright I found that this is a feature of a classloaders architecture which counts on there're no duplicate classes across deployed applications. But could the error be handled somehow? -- Comment By: Alexei Yudichev (sflexus) Date: 2002-09-16 19:28 Message: Logged In: YES user_id=345880 I have changed my custom exception to JavaMail's AddressException and the problem still persists. Then I've removed application exceptions entirely and at last everything started to work well. So the problem doesn't depend on whether declared in bean interface exceptions are packaged with application or they are standard exceptions loaded from jbosshome/server//lib jars. -- Comment By: Alexei Yudichev (sflexus) Date: 2002-09-16 18:52 Message: Logged In: YES user_id=345880 I have changed my custom exception to JavaMail's AddressException and the problem still persists. Then I've removed application exceptions entirely and at last everything started to work well. So the problem doesn't depend on whether declared in bean interface exceptions are packaged with application or they are standard exceptions loaded from jbosshome/server//lib jars. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=609902&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610552 ] PrefixDeploymentSorter and non-digit URL
Bugs item #610552, was opened at 2002-09-17 16:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610552&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: PrefixDeploymentSorter and non-digit URL Initial Comment: If using org.jboss.deployment.scanner.PrefixDeploymentSorter those files beginning with non-digit are deployed FIRST, not LAST as declared in comments inside jboss-service.xml. This is because private int getPrefixValue(URL url) returns -1 if no digital prefix exists. It should return Integer.MAX_VALUE or something. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610552&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610531 ] JMSXGroupID Property unusable
Bugs item #610531, was opened at 2002-09-17 15:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610531&group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Lars Klose (klosels) Assigned to: Nobody/Anonymous (nobody) Summary: JMSXGroupID Property unusable Initial Comment: In JBoss 3.0.2 handling of the "JMSXGroupID" property defined in the JMS spec is not correct: while org.jboss.mq.SpyConnectionMetaData.getJMSXPropertyNames returns "JMSXGroupID" as one of the available properties, using this String as the property name in a call to org.jboss.mq.SpyMessage.setStringProperty fails because in org.jboss.mq.SpyMessage.CheckPropertyName it will be checked against "JMSGroupId". Note the different spelling Id vs ID! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610531&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Should modelmbean forward MBeanRegistration calls to managedresource?
The question is not should but can? :-) The spec requires the MBeanServer to invoke the ModelMBean's pre/post[De]Register. It is silent on whether the ModelMBean forwards that to the "pojo". The pojo implementing the interface should be enough configuration shouldn't it? Regards, Adrian >From: David Jencks <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: jboss-dev <[EMAIL PROTECTED]> >Subject: [JBoss-dev] Should modelmbean forward MBeanRegistration calls to >managed resource? >Date: Tue, 17 Sep 2002 00:35:23 -0400 > >I think it's an oversight... shouldn't modelMbean forward the >MBeanRegistration calls to the managed resource if that resource implements >MBeanRegistration? > >Our ServiceMBeanSupport subclasses need these calls to get the server and >their objectName. I've added this so subclasses can be xmbeans. Should >this be configurable by descriptors? > >Thanks >david jencks > > >--- >Sponsored by: AMD - Your access to the experts on Hammer Technology! >Open Source & Linux Developers, register now for the AMD Developer >Symposium. Code: EX8664 http://www.developwithamd.com/developerlab >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
sorry.. forgot to add my renamed file. Should be fixed now. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > [EMAIL PROTECTED] > Sent: Tuesday, September 17, 2002 7:45 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed > > > > = > ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= > = > > JAVA VERSION DETAILS > java version "1.3.1_03" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) > Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) > > = > > HERE ARE THE LAST 50 LINES OF THE LOG FILE > > /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss > /aspect/AspectClassLoader.java:165: cannot resolve symbol > symbol : class AspectDefinition > location: class org.jboss.aspect.AspectClassLoader > return (AspectDefinition) aspectDefinitions.get(clazz); > ^ --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.4.0_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectClassLoader.java:165: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectClassLoader return (AspectDefinition) aspectDefinitions.get(clazz); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:150: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:170: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:188: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:245: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory return (AspectDefinition)aspects.get(aspect); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/proxy/ProxyTemplate.java:47: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.proxy.ProxyTemplate AspectDefinition ac = acl.getAspectDefinition(getClass()); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/util/XMLConfiguration.java:45: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.util.XMLConfiguration AspectDefinition c = loadAspectObjectDefinition(aspectXML); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/util/XMLConfiguration.java:95: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.util.XMLConfiguration return new AspectDefinition(name, interceptors, interceptorConfigs, targetClass); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:369: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ 24 errors 8 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:322: Compile failed; see the compiler error output for details. Total time: 3 minutes 36 seconds --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] libraries.ent
I think this is a big improvement, thanks david jencks On 2002.09.17 05:12:01 -0400 Dain Sundstrom wrote: > David, > > I have rewritten the libraries.ent file in the applications cvs project > to have each library check if the files are in the thirdparty directory, > and only then declare the properties and classpath. I think this is a > better solution to the library problem because it moves the decision > about what to include to the CVSROOT/modules file. > > What do you think? > > -dain > > -- > > Dain Sundstrom > Chief Architect JBossCMP > JBoss Group, LLC > > > > > --- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectClassLoader.java:165: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectClassLoader return (AspectDefinition) aspectDefinitions.get(clazz); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:150: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:170: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:188: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:245: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory return (AspectDefinition)aspects.get(aspect); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/proxy/ProxyTemplate.java:47: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.proxy.ProxyTemplate AspectDefinition ac = acl.getAspectDefinition(getClass()); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/util/XMLConfiguration.java:45: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.util.XMLConfiguration AspectDefinition c = loadAspectObjectDefinition(aspectXML); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/util/XMLConfiguration.java:95: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.util.XMLConfiguration return new AspectDefinition(name, interceptors, interceptorConfigs, targetClass); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:369: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ 24 errors 4 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:322: Compile failed; see the compiler error output for details. Total time: 3 minutes 13 seconds --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE _servlet-library: _jasper-library-available: _jasper-library: _jaas-library-available: _jaas-library: _jaf-library-available: _jaf-library: _javacc-library-available: _javacc-library: _jce-library-available: _jce-library: _javamail-library-available: _javamail-library: _jsse-library-available: _jsse-library: _jts-library-available: _jts-library: libraries: xdoclet-base: ejbdoclet-def: webdoclet-def: xdoclet: configure: BUILD FAILED jar:file:/disk/orig/home/lubega/jbossro/jboss-all/tools/lib/buildmagic-tasks.jar!/org/jboss/tools/buildmagic/common.xml:68: Reference sun.jndi.classpath not found. Total time: 20 seconds --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MarshalException for Remote Invocation (610392)
I haven't looked at the code, I've just been thinking about how to make the jboss tm distributed. First, until the jboss tm is distributed, it seems to me that problems invoking an ejb on another server from inside a tx using the jboss tm are appropriate, since the tx can't be propagated. Using tyrex or the future enhanced jboss tm, I believe there has to be an XAResource somewhere near the remote invoker or proxy that gets the tm to produce an xid branch for the tx on the other server. IMO the Xid is what should get serialized and sent over. I've been thinking that a client interceptor would be the place for the XAResource. On the other side, something needs to take the xid and create a transaction on the 2nd server, associated with this xid. The "something" is implemented in jboss 4 in the jca 1.5 support. WIth Tyrex, I imagine they must have code that does this stuff. Does the tyrex integration code appear to be trying to do any of this? Thanks david jencks On 2002.09.17 03:18:15 -0400 Brian Towles wrote: > Howdy all > > Repeating what be bug said.. (just for frame of reference) > > -- > A Marshaling Exception is being thrown the remote > invoker when any remote EJB function is called > (inter-jboss). Even when using Tyrex as a transaction > manager. > > This is being caused by the Transaction Implmentation > being placed in the MarshalledInvocation's > as_is_payload Map. This is preventing any remote > invocation because the TransactionImpl for both jboss > and tyrex are not serializable. > > For a remote invocation it is my understanding that > only the TransactionPropogationContext (TPC) is what is > needed to migrate the transaction for remote > invocation. The TPC is being placed in the in the > MarshaledInvocation correctly. > -- > > Ive been hunting this one down for a while and I would like some advice > on what a proper fix would be. > > Would simply putting it into the transient_payload keep things working > internally? Theoretically it should then not be marshaled and the TPC > should be the transaction propagation mechanism for remote. > > Right now I'm looking for a quick solution cause I have a deadline to > meet. (don't we all). > > Any hints would help > > Thanks > -=Brian > > > > > > > > --- > Sponsored by: AMD - Your access to the experts on Hammer Technology! > Open Source & Linux Developers, register now for the AMD Developer > Symposium. Code: EX8664 http://www.developwithamd.com/developerlab > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.4.0_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE _jasper-library: _jaas-library-available: _jaas-library: _jaf-library-available: _jaf-library: _javacc-library-available: _javacc-library: _jce-library-available: _jce-library: _javamail-library-available: _javamail-library: _jndi-library-available: _jndi-library: _jsse-library-available: _jsse-library: _jts-library-available: _jts-library: libraries: xdoclet-base: ejbdoclet-def: webdoclet-def: xdoclet: configure: BUILD FAILED jar:file:/disk/orig/home/lubega/jbossro/jboss-all/tools/lib/buildmagic-tasks.jar!/org/jboss/tools/buildmagic/common.xml:68: Reference sun.jndi.classpath not found. Total time: 22 seconds --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE _jasper-library: _jaas-library-available: _jaas-library: _jaf-library-available: _jaf-library: _javacc-library-available: _javacc-library: _jce-library-available: _jce-library: _javamail-library-available: _javamail-library: _jndi-library-available: _jndi-library: _jsse-library-available: _jsse-library: _jts-library-available: _jts-library: libraries: xdoclet-base: ejbdoclet-def: webdoclet-def: xdoclet: configure: BUILD FAILED jar:file:/disk/orig/home/lubega/jbossro/jboss-all/tools/lib/buildmagic-tasks.jar!/org/jboss/tools/buildmagic/common.xml:68: Reference sun.jndi.classpath not found. Total time: 1 minute 46 seconds --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] libraries.ent
David, I have rewritten the libraries.ent file in the applications cvs project to have each library check if the files are in the thirdparty directory, and only then declare the properties and classpath. I think this is a better solution to the library problem because it moves the decision about what to include to the CVSROOT/modules file. What do you think? -dain -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Sun and Jboss
Hmmm... I thought only the JBoss Group services were a for-profit project, whereas the JBoss open source server was a non-profit project. But maybe I am wrong in this distinction? Randahl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: 17. september 2002 10:34 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Sun and Jboss http://java.sun.com/features/2002/09/opn_src_cooper.html TH folowing is from a interview with Danese Cooper posted on java.sun.com Question: JBoss Compatibility In a recent survey, a lot of developers want to know when Sun will allow JBoss to be branded as compatible with Java technology. Answer: Yeah, that's a really tough situation. JBoss is an open source project that wants to say they are compatible with J2EE, but they are also a for-profit project, so they can't apply for zero-cost access to the TCKs under the new rules. Recently JBoss launched its own certification program, which is interesting. Open source wisdom says that it's really hard to maintain a fork. It will be interesting to see how they do. I'd really like to see Sun and JBoss work together to find a solution to the problem. They got great coverage at the 2002 JavaOneSM conference -- several awards. It's a very popular effort. __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610008 ] Verifier too strict for 2.0 cmp 1.1 home
Bugs item #610008, was opened at 2002-09-16 18:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) >Assigned to: Christian Riege (lqd) Summary: Verifier too strict for 2.0 cmp 1.1 home Initial Comment: The verifier is validating 2.0 EJBs that use 1.1 cmp as EJB 1.1 beans. This fails when the home includes method forms from the EJB 2.0 spec, which should be allowed. See the current failures to deploy the org.jboss.test.testbean.test.BeanUnitTestCase testbean.jar in either 3.2 or main. -- >Comment By: Christian Riege (lqd) Date: 2002-09-17 10:56 Message: Logged In: YES user_id=176671 I will have a look at this but from my memory the current architecture of the Verifier doesn't allow for an easy fix for this -- it's either 2.0 or 1.1 all the way. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610008&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Sun and Jboss
http://java.sun.com/features/2002/09/opn_src_cooper.html TH folowing is from a interview with Danese Cooper posted on java.sun.com Question: JBoss Compatibility In a recent survey, a lot of developers want to know when Sun will allow JBoss to be branded as compatible with Java technology. Answer: Yeah, that's a really tough situation. JBoss is an open source project that wants to say they are compatible with J2EE, but they are also a for-profit project, so they can't apply for zero-cost access to the TCKs under the new rules. Recently JBoss launched its own certification program, which is interesting. Open source wisdom says that it's really hard to maintain a fork. It will be interesting to see how they do. I'd really like to see Sun and JBoss work together to find a solution to the problem. They got great coverage at the 2002 JavaOneSM conference -- several awards. It's a very popular effort. __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.4.0_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectClassLoader.java:165: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectClassLoader return (AspectDefinition) aspectDefinitions.get(clazz); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:150: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:170: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:188: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:245: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory return (AspectDefinition)aspects.get(aspect); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/proxy/ProxyTemplate.java:47: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.proxy.ProxyTemplate AspectDefinition ac = acl.getAspectDefinition(getClass()); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/util/XMLConfiguration.java:45: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.util.XMLConfiguration AspectDefinition c = loadAspectObjectDefinition(aspectXML); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/util/XMLConfiguration.java:95: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.util.XMLConfiguration return new AspectDefinition(name, interceptors, interceptorConfigs, targetClass); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:369: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ 24 errors 8 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:323: Compile failed; see the compiler error output for details. Total time: 3 minutes 13 seconds --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608458 ] subdeployments in wsr
Bugs item #608458, was opened at 2002-09-12 18:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608458&group_id=22866 Category: JBossSOAP Group: v4.0 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Dr. Christoph Georg Jung (cgjung) Assigned to: Dr. Christoph Georg Jung (cgjung) Summary: subdeployments in wsr Initial Comment: have been accidently disabled. Should be enabled, again -- >Comment By: Dr. Christoph Georg Jung (cgjung) Date: 2002-09-17 10:17 Message: Logged In: YES user_id=175199 done in head and 3.2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608458&group_id=22866 --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-582428 ] ejb remove cause IllegalStateException
Bugs item #582428, was opened at 2002-07-16 22:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=582428&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Andrew Lau (andrewlau4) Assigned to: Bill Burke (patriot1burke) Summary: ejb remove cause IllegalStateException Initial Comment: This problem happens in jboss 3.0 and 3.0.1 RC1 I have a parent entity bean that I have set to 'cascade delete' all its children. But when I try to remove that bean, I sometimes got the following exception: . java.lang.IllegalStateException: removing bean lock and it has tx set! at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.r emoveRef(QueuedPessimisticEJBLock.java:469) at org.jboss.ejb.BeanLockManager.removeLockRef (BeanLockManager.java:78) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke (EntityLockInterceptor.java:124) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke (EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.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.EntityContainer.invoke (EntityContainer.java:493) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBri dge.invokeRemoveRelation (JDBCCMRFieldBridge.java:759) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBri dge.destroyRelationLinks (JDBCCMRFieldBridge.java:696) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBri dge.destroyRelationLinks (JDBCCMRFieldBridge.java:674) at org.jboss.ejb.plugins.cmp.jdbc.bridge.RelationSet.clear (RelationSet.java:163) .. But I may have found a quick solution for now. The IllegalStateException exception only happens when I call EJBLocalObject remove() method. Now I changed my code so it calls EJBLocalHome remove() method instead. Since then, it seems working fine so far. -- Comment By: Alexei Yudichev (sflexus) Date: 2002-09-17 11:05 Message: Logged In: YES user_id=345880 This exception MAY (or may not) happen when children are being removed from relation either expicitly by calling cmr setXXX method or implicitly by removing children or the parent. -- Comment By: Alexei Yudichev (sflexus) Date: 2002-09-12 12:39 Message: Logged In: YES user_id=345880 Also it happens sometimes when I try to invoke cmr set method with many-to-one relationship. Is this bug about to be fixed in nearest future? Because otherwise I will have to move our project from jboss or from ejb 2.0 and it will take much time. 2002-09-12 12:29:08,719 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException, causedBy: java.lang.IllegalStateException: removing bean lock and it has tx set! at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.removeRef(QueuedPessimisticEJBLock.java:473) at org.jboss.ejb.BeanLockManager.removeLockRef(BeanLockManager.java:78) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:124) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:232) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.invokeGetRelatedId(JDBCCMRFieldBridge.java:640) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.createRelationLinks(JDBCCMRFieldBridge.java:570) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.setInstanceValue(JDBCCMRFieldBridge.java:545) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.setValue(JDBCCMRFieldBridge.java:483) at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:125) at org.jboss.proxy.compiler.Runtime.invoke(Runtime.java:59) at com.tw.mms.ejb.SlideBean$Proxy.setSound() at com.tw.mms.ejb.SlideBean.setSoundId(SlideBean.java:185) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessor
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectClassLoader.java:165: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectClassLoader return (AspectDefinition) aspectDefinitions.get(clazz); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:150: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:170: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:188: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory AspectDefinition composition = getDefinition(aspectName); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/AspectFactory.java:245: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.AspectFactory return (AspectDefinition)aspects.get(aspect); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/proxy/ProxyTemplate.java:47: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.proxy.ProxyTemplate AspectDefinition ac = acl.getAspectDefinition(getClass()); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/util/XMLConfiguration.java:45: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.util.XMLConfiguration AspectDefinition c = loadAspectObjectDefinition(aspectXML); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/aspect/util/XMLConfiguration.java:95: cannot resolve symbol symbol : class AspectDefinition location: class org.jboss.aspect.util.XMLConfiguration return new AspectDefinition(name, interceptors, interceptorConfigs, targetClass); ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:369: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ 24 errors 4 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:323: Compile failed; see the compiler error output for details. Total time: 3 minutes 10 seconds --- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
