[JBoss-dev] [ jboss-Bugs-601049 ] MarshalException in serializing Handle
Bugs item #601049, was opened at 2002-08-27 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=601049group_id=22866 Category: JBossServer Group: v3.1 Status: Open Resolution: None Priority: 5 Submitted By: Yan Pujante (madonnax) Assigned to: Nobody/Anonymous (nobody) Summary: MarshalException in serializing Handle Initial Comment: I have the following code: // userSession is stateful session bean Handle ser = userSession.getHandle(); ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(ser); this throws the following exception: 15:57:19,944 ERROR [STDERR] java.rmi.MarshalException: Invalid remote object 15:57:19,946 ERROR [STDERR] at java.rmi.server.RemoteObject.writeObject(RemoteObject.java:332) 15:57:19,948 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 15:57:19,950 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 15:57:19,951 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 15:57:19,952 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 15:57:19,953 ERROR [STDERR] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:780) 15:57:19,955 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1294) 15:57:19,956 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245) 15:57:19,957 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) 15:57:19,961 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) 15:57:19,962 ERROR [STDERR] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.writeExternal(JRMPInvokerProxy.java:149) 15:57:19,963 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1265) 15:57:19,965 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1243) 15:57:19,966 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) 15:57:19,967 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330) 15:57:20,118 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302) 15:57:20,119 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245) 15:57:20,120 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) 15:57:20,121 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) A javax.ejb.Handle is supposed to be serializable so this should work. OS: Solaris 8 JDK 1.4.0_01 jboss: jboss-3.0.1RC1_tomcat-4.0.4 -- Comment By: Sandra Schmidt (sandresen) Date: 2002-09-25 06:40 Message: Logged In: YES user_id=617171 My problem is similar to yours. I tried to save the RemoteInterfaceHandle of a Stateful Session Bean in HttpSession with the same errormessage as a result. javax.ejb.Handle is an Interface, so what really is stored in the session is the implementation of that interface. I found out that org.jboss.proxy.ejb.handle.StatefulHandleImpl which implements javax.ejb.Handle contains an instance of org.jboss.invocation.Invoker which seems to be not serializable (respectively the class that implements the invoker- interface: org.jboss.invocation.jrmp.interfaces.JRMPInvokerPr oxy). Don`t know, if that helps or if that is the root cause of the error but I hope that something about this problem is done or at least a workaround is presented. OS: Windows XP JDK 1.4.0 with JBoss 3.0.2_tomcat 4.0.4 -- Comment By: Bernd Zeitler (frito) Date: 2002-08-30 10:55 Message: Logged In: YES user_id=603154 I did encounter the same difficulties. The handle of a SSB you obtain in a java application is serializable, while the handle you obtain inside JBoss is not. OS: W2K JDK 1.4.0_01 with JBoss 3.0.0_tomcat-4.0.3, JBoss 3.0.1_tomcat-4.0.4, JBoss 3.0.2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=601049group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-614291 ] EJBProvider for statefull session bean
Patches item #614291, was opened at 2002-09-25 11:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=614291group_id=22866 Category: JbossSOAP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Infogest (infogest) Assigned to: Nobody/Anonymous (nobody) Summary: EJBProvider for statefull session bean Initial Comment: This patch against 3.2.0-beta1 allows to use statefull session beans with jboss-net. It will remove the session bean when the http session expires. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=614291group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-614313 ] TxManager memory leak
Bugs item #614313, was opened at 2002-09-25 12:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=614313group_id=22866 Category: JBossTX Group: v3.2 Status: Open Resolution: None Priority: 6 Submitted By: Michael Bartmann (bartmann) Assigned to: Nobody/Anonymous (nobody) Summary: TxManager memory leak Initial Comment: The TxManager stores all allocated TransactionImpl instances in a private HashMap (globalIdTx). The only package-private method releaseTransactionImp which would clear them from the HashMap does not seam to be called from anywhere. This is a leak which costs us 100MB per day on a medium trafic server. (Each TransactionImpl itself holds an XIdImpl, a Logger, ...) Regards, Michael Bartmann -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=614313group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-614313 ] TxManager memory leak
Bugs item #614313, was opened at 2002-09-25 12:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=614313group_id=22866 Category: JBossTX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Bartmann (bartmann) Assigned to: Nobody/Anonymous (nobody) Summary: TxManager memory leak Initial Comment: The TxManager stores all allocated TransactionImpl instances in a private HashMap (globalIdTx). The only package-private method releaseTransactionImp which would clear them from the HashMap does not seam to be called from anywhere. This is a leak which costs us 100MB per day on a medium trafic server. (Each TransactionImpl itself holds an XIdImpl, a Logger, ...) Regards, Michael Bartmann -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=614313group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-597216 ] Jetty in 3.0.1 has broken Jasper
Bugs item #597216, was opened at 2002-08-19 16:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=597216group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty in 3.0.1 has broken Jasper Initial Comment: JBoss Release 3.0.1, JDK1.4, Solaris 2.8 The Jetty included in this release contains a broken version of Jasper. As far as I remember it's a version from one of the Tomcat 4.0.4 Betas. I recognize it, because it always prints sun.tools.javac.Main has been deprecated., if a JSP compilation error occurred. Harmless. But: I am using the JSTL1.0 and the Jetty compiler chokes on some perfectly legal c:if/c:if constructs, just like Tomcat 4.0.4Beta(?) did. Could you please update Jasper to a newer version (4.1.x) where this bug has been fixed? OBTW: Shouldn't there be a Jetty category in the sf submit new bug form? Thanks. Georg -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-09-25 10:41 Message: Logged In: YES user_id=44062 Jetty has been upgraded to use the jasper from tomcat 4.1.10 and this has been moved to JBoss CVS and is used in recent releases of JBoss, including 3.0.2 and 3.2.0b. Note you can simply drop in a new jasper.jar if you need a different vesion -- Comment By: Scott M Stark (starksm) Date: 2002-09-24 21:29 Message: Logged In: YES user_id=175228 This is now out of date as jasper was updated in 3.0.2 and 3.0.3 -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-08-19 18:38 Message: Logged In: YES user_id=44062 We have been taking jasper from the head of tomcat 4 CVS. But I see they have created a separate CVS tree for jasper now, so I'll have a look see and try to work out what is the latest/best Not always easy with jakarta :-) regards -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=597216group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Restricting ejb-name values
Hi everyone, I'm currently working on resolving Bug #613360 (see https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_id=22866 ). I have an implementation issue with the EJB Spec Section 10.6.14: The Bean Provider should not use reserved identifiers as ejb-names or abstract-schema-names. Reserved identifiers are discussed in Section 11.2.6.1. Even more restrictive is section 10.3.13: The ejb-name must be a valid Java identifier This explicitly disallows something which is quite popular today, e.g. ejb-nameorg/jboss/ABean/ejb-name Thus possibly a lot of deployments will break. If you take the spec literally this only applies to CMP 2.0 Entity Beans (the other sections don't talk about ejb-name element a lot, the DTD only talks about ejb-name being restricted to the XML 1.0 'NMTOKEN' specification). I need a handcount as to how restrictive should JBoss be, please check one of the options below: [ ] ejb-name should be restricted as specified above for ALL EJB's [ ] ejb-name should be restricted as above ONLY for CMP 2.0 Entity Beans My vote is to enforce these restrictions for ALL beans. A lot easier to implement and it has the advantage of being consistent throughout JBoss. Consistency is a Good Thing(tm). Regards + thanks for your input, Christian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss-Jetty fresher...
Hello, I am new in JBoss-Jetty users. I have downloaded JBoss-all 3.0. It has build-in Jetty server. Now I have to add a simple JSP project to the Jetty server. So that, when I will run server and give 'http://Localhost/Myapp/index.jsp' it should show index.jsp file in browser. Can anyone please guide me to do this. I am not getting exactly where to add my JSP files, and which XML files to be modified and how to rebuild all stuff. I need it urgently, Anxiousfor response, Vikram.
Re: [JBoss-dev] Restricting ejb-name values
[x ] ejb-name should be restricted as above ONLY for CMP 2.0 Entity Beans There really is no point to restricting the names in other contexts that I can see as it will only introduce compatibility problems. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Christian Riege [EMAIL PROTECTED] To: JBoss Dev list [EMAIL PROTECTED] Sent: Wednesday, September 25, 2002 4:29 AM Subject: [JBoss-dev] Restricting ejb-name values Hi everyone, I'm currently working on resolving Bug #613360 (see https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_id=22866 ). I have an implementation issue with the EJB Spec Section 10.6.14: The Bean Provider should not use reserved identifiers as ejb-names or abstract-schema-names. Reserved identifiers are discussed in Section 11.2.6.1. Even more restrictive is section 10.3.13: The ejb-name must be a valid Java identifier This explicitly disallows something which is quite popular today, e.g. ejb-nameorg/jboss/ABean/ejb-name Thus possibly a lot of deployments will break. If you take the spec literally this only applies to CMP 2.0 Entity Beans (the other sections don't talk about ejb-name element a lot, the DTD only talks about ejb-name being restricted to the XML 1.0 'NMTOKEN' specification). I need a handcount as to how restrictive should JBoss be, please check one of the options below: [ ] ejb-name should be restricted as specified above for ALL EJB's My vote is to enforce these restrictions for ALL beans. A lot easier to implement and it has the advantage of being consistent throughout JBoss. Consistency is a Good Thing(tm). Regards + thanks for your input, Christian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-614116 ] Oracle XA pooling/repeated rollback
Bugs item #614116, was opened at 2002-09-24 19:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Oracle XA pooling/repeated rollback
Initial Comment:
I've been trying to isolate some problems I've been
having with transaction roll-backs and message-driven
beans. Basically, when a transaction is rolled-back
a number of times in the onMessage() body
(by calling MessageDrivenContext.setRollbackOnly()
5-10 times in succession),
the message is re-delivered to the MDB, but the Oracle
Connection is no longer in a good state.
This problem manifests itself when using a very small
connection pool (say 1-5) connections.
Example code snippet:
public void onMessage(javax.jms.Message jmsMessage)
{
Connection c = null;
try {
TextMessage tm = (TextMessage)jmsMessage;
String text = tm.getText();
c = ds.getConnection();
PreparedStatement s = c.prepareStatement(insert into test values (?));
s.setString(1, text);
s.executeUpdate();
mdc.setRollbackOnly();
} catch (Exception e) {
throw new EJBException(e);
} finally {
if (c != null) {
try { c.close(); }
catch (Exception e) {
e.printStackTrace();
}
}
First I see it works for a few times. It rolls-back successfully
about 5 or 6 times. Then, for no reason, I see:
15:50:44,922 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.delistResource(TxCapsule.java:579)
at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:92)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.delist(XATxConnectionManager.java:284)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.connectionClosed(XATxConnectionManager.java:331)
at
org.jboss.resource.adapter.jdbc.BaseManagedConnection.fireConnectionEvent(BaseManagedConnection.java:152)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.fireConnectionEvent(XAManagedConnection.java:215)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection$1.connectionClosed(XAManagedConnection.java:127)
at
oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:482)
at
oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:445)
at oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:2900)
at oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1418)
at com.proteusmobile.smx.AMDB.onMessage(AMDB.java:140)
Later:
15:50:44,929 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1312)
at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:440)
at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:83)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:301)
at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:603)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:417)
at org.jboss.mq.SpySession.run(SpySession.java:259)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655)
at java.lang.Thread.run(Thread.java:479)
And then, I can no longer get a connection:
15:50:44,971 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//5,
BranchQual=] errorCode=XAER_PROTO
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.disallowLocalTxnMode(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:153)
at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:679)
at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:102)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:262)
at
[JBoss-dev] sources for hsqldb
I find the hsqldb.jar under thirdparty. But it contains classes not in the release I obtained from the orig. HSQLDB-Project. I need the sources to find the reason for a thread leak, especially org.hsqldb.Embedded_Server which I find in the jboss's version of hsqldb.jar. Thanks, Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ JBoss.Net developers,
After working with wsdl2Java, I have come to the conclusion that the wsdl
being generated by org.jboss.net.jmx.server.MBeanProvider is not accurate.
I have included both the WSDL and the interface generated by wsdl2Java. Any
ideas? It seems to me that the method signatures of my MBean should show up
in the wsdl. Is this an accurate assumption? If so, what might be
preventing accurate wsdl generation in this case?
- Matt
?xml version=1.0 encoding=UTF-8?
wsdl:definitions
targetNamespace=http://localhost:8080/jboss-net/services/CustomTerminologyM
anagementService xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:apachesoap=http://xml.apache.org/xml-soap;
xmlns:impl=http://localhost:8080/jboss-net/services/CustomTerminologyManage
mentService
xmlns:intf=http://localhost:8080/jboss-net/services/CustomTerminologyManage
mentService xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
wsdl:portType name=XMBean
/wsdl:portType
wsdl:binding name=CustomTerminologyManagementServiceSoapBinding
type=impl:XMBean
wsdlsoap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http/
/wsdl:binding
wsdl:service name=XMBeanService
wsdl:port binding=impl:CustomTerminologyManagementServiceSoapBinding
name=CustomTerminologyManagementService
wsdlsoap:address
location=http://localhost:8080/jboss-net/services/CustomTerminologyManageme
ntService/
/wsdl:port
/wsdl:service
/wsdl:definitions
/**
* XMBean.java
*
* This file was auto-generated from WSDL
* by the Apache Axis WSDL2Java emitter.
*/
package localhost;
public interface XMBean extends java.rmi.Remote {
}
-Original Message-
From: Matt Munz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 24, 2002 10:49 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ,
Thanks for your response.
A) generate wsdl from the deployed web services.
B) generate stub classes from the wsdl using wsdl2java.
This is the first thing that I tried and it did not work. I didn't take a
lot of time to firgure out why this is the case, since the jboss.net
testcase code was easy to understand, so I may have missed something
simple...
This may work for simple cases, but once you declare additional
data structures and serializers, it becomes very hairy on the client side,
otherwise.
Well, for my purposes, I don't intend on sending complex Object graphs
over the wire. I also think that the Bean Serializer should be sufficient
for my purposes. By may work, do you mean will work without errors for
simple cases, or probably won't work for any case, so don't even try it?
Is there a test case that demonstrates the technique (A B above) that
you reccommend? I would find this quite useful. If I have time, I'll try
to write one myself, if it doesn't already exist.
On code generation in general, I must admit that I have a bit of healthy
skepticism on the matter. In this example, the amount of client side code
required to use the deprecated technique totals no more than a few lines,
while the output of wsdl2java comprises multiple full-fledged classes. It
seems to me that, auto-generated or not, this compromises a significant
ramp-up in code maitennance costs.
Based on your experience, what makes code generation the way to go in this
case? Do you find the generated code reasonable, easy to maintain,
scalable, reliable, etc.?
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jung
, Dr. Christoph
Sent: Tuesday, September 24, 2002 10:06 AM
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] writing a jboss.net (jmx.net?) client
Matt,
For getting the client-side invocations and stub classes right, we recommend
The following steps:
A) generate wsdl from the deployed web services.
B) generate stub classes from the wsdl using wsdl2java.
Using Axis/MbeanInvocationHandler lacks a lot of deployment information
(basically,
The client-side of the web-service.xml) that we try to default
from java reflection.
This may work for simple cases, but once you declare additional
data structures and serializers, it becomes very hairy on the client side,
otherwise.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 20. September 2002 17:41
An: JBoss Developers Group
Betreff: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ JBoss.Net Developers,
First, let me say Thank you. I now have MBeans in the server exposed as
web services. Although it took a bit of research to figure out how to do
this, the minimal amount of (xml) code required to expose MBeans as
webservices (should I call this JMX.Net?) speaks for itself.
I was again pleased to see that the client side is also straightforward,
once I knew what to do. Basically, I
[JBoss-dev] JSP Error
Hello, I am using JBoss3.0. I have a small project developed and deployedin war file. The project contains some JSPs. When I start server and open JSP using url as follows 'http://localhost:8080/test/test/index.jsp', then I get error as... HTTP ERROR: 500 Unable to compile class for JSP An error occurred at line: 14 in the jsp file: /cal/cal1.jsp Generated servlet error: C:\TEMP\Jetty__8080___cal\cal\cal1$jsp.java:65: Class cal.TableBean not found. cal.TableBean table = null; ^ An error occurred at line: 14 in the jsp file: /cal/cal1.jsp Generated servlet error: C:\TEMP\Jetty__8080___cal\cal\cal1$jsp.java:68: Class cal.TableBean not found. table= (cal.TableBean) ^ An error occurred at line: 14 in the jsp file: /cal/cal1.jsp Generated servlet error: C:\TEMP\Jetty__8080___cal\cal\cal1$jsp.java:73: Class cal.TableBean not found. table = (cal.TableBean) java.beans.Beans.instantiate(this.getClass().getClassLoader(), "cal.TableBean"); ^ An error occurred between lines: 38 and 41 in the jsp file: /cal/cal1.jsp Generated servlet error: C:\TEMP\Jetty__8080___cal\cal\cal1$jsp.java:110: Class cal.Entry not found. cal.Entry entr = table.getEntries().getEntry(i); ^ 4 errors RequestURI=/cal/cal/cal1.jsp Can anybody please suggest me what might be wrong. If Iopen JSP file seperately in browser, then it opens properly. Regards, Vikram.
Re: [JBoss-dev] Restricting ejb-name values
I has to be restricted for CMP 2.0 beans as the code assumes that the name is a valid java identifier. -dain Scott M Stark wrote: [x ] ejb-name should be restricted as above ONLY for CMP 2.0 Entity Beans There really is no point to restricting the names in other contexts that I can see as it will only introduce compatibility problems. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Christian Riege [EMAIL PROTECTED] To: JBoss Dev list [EMAIL PROTECTED] Sent: Wednesday, September 25, 2002 4:29 AM Subject: [JBoss-dev] Restricting ejb-name values Hi everyone, I'm currently working on resolving Bug #613360 (see https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_id=22866 ). I have an implementation issue with the EJB Spec Section 10.6.14: The Bean Provider should not use reserved identifiers as ejb-names or abstract-schema-names. Reserved identifiers are discussed in Section 11.2.6.1. Even more restrictive is section 10.3.13: The ejb-name must be a valid Java identifier This explicitly disallows something which is quite popular today, e.g. ejb-nameorg/jboss/ABean/ejb-name Thus possibly a lot of deployments will break. If you take the spec literally this only applies to CMP 2.0 Entity Beans (the other sections don't talk about ejb-name element a lot, the DTD only talks about ejb-name being restricted to the XML 1.0 'NMTOKEN' specification). I need a handcount as to how restrictive should JBoss be, please check one of the options below: [ ] ejb-name should be restricted as specified above for ALL EJB's My vote is to enforce these restrictions for ALL beans. A lot easier to implement and it has the advantage of being consistent throughout JBoss. Consistency is a Good Thing(tm). Regards + thanks for your input, Christian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMS DestinationManager issue with Remote queues and MDB's
I am using the 3.2.0beta2 CVS version of JBoss and have run into a problem with the JMS DestinationManager. It appears that the JMS DestinationManager stores in a hashmap the actual queue/topic JNDI names that are then looked up at deployment time by the MDB deployment logic in JBoss. This works fine for local queues and topics as the internal hashmap that the DestinationManager uses has entries (ie destinations) for each of the local queues that were deployed in the jbossmq-destinations.xml file on startup. However, in the case of remote queues, the hashmap does not have the JNDI names of those queues and thus the MDB deploys with an error saying it cannot find the queue to bind to. I find this coupling of the MDB deployer to the local DestinationManager odd in that you are allowed to use the ProviderUrl on the JMSProviderLoader service to point to a remote JBoss instance that houses the queues. I have my MDB confired to use the Remote JMSProviderLoader I setup, and JBoss is deploying the JMSProviderLoader which in turn is binding to the remote JNDI context. However, the local DestinationManager is still being used in that setup to look up queue names even though it only has local queue names, not the remote ones. I looked through the JBossMQ code base and really didn't see any way to have the MDB deployer do a real JNDI lookup for the queue on a remote host. It appears that the MDB deployment system is setup to always use the DestinationManager for doing it's JNDI resource lookups. Any tips would be greatly appreciated. Dustin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] writing a jboss.net (jmx.net?) client
Matt,
MBeanProvider should normally reflect over the JMX-Metadata (hence also the
mbean methods) to
Build the wsdl. But I havn´t looked at the code for a while. Let met check
this.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 25. September 2002 17:08
An: Matt Munz; [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ JBoss.Net developers,
After working with wsdl2Java, I have come to the conclusion that the wsdl
being generated by org.jboss.net.jmx.server.MBeanProvider is not accurate. I
have included both the WSDL and the interface generated by wsdl2Java. Any
ideas? It seems to me that the method signatures of my MBean should show up
in the wsdl. Is this an accurate assumption? If so, what might be
preventing accurate wsdl generation in this case?
- Matt
?xml version=1.0 encoding=UTF-8?
wsdl:definitions
targetNamespace=http://localhost:8080/jboss-net/services/CustomTerminologyM
anagementService xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:apachesoap=http://xml.apache.org/xml-soap;
xmlns:impl=http://localhost:8080/jboss-net/services/CustomTerminologyManage
mentService
xmlns:intf=http://localhost:8080/jboss-net/services/CustomTerminologyManage
mentService xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
wsdl:portType name=XMBean
/wsdl:portType
wsdl:binding name=CustomTerminologyManagementServiceSoapBinding
type=impl:XMBean
wsdlsoap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http/
/wsdl:binding
wsdl:service name=XMBeanService
wsdl:port binding=impl:CustomTerminologyManagementServiceSoapBinding
name=CustomTerminologyManagementService
wsdlsoap:address
location=http://localhost:8080/jboss-net/services/CustomTerminologyManageme
ntService/
/wsdl:port
/wsdl:service
/wsdl:definitions
/**
* XMBean.java
*
* This file was auto-generated from WSDL
* by the Apache Axis WSDL2Java emitter.
*/
package localhost;
public interface XMBean extends java.rmi.Remote {
}
-Original Message-
From: Matt Munz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 24, 2002 10:49 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ,
Thanks for your response.
A) generate wsdl from the deployed web services.
B) generate stub classes from the wsdl using wsdl2java.
This is the first thing that I tried and it did not work. I didn't take a
lot of time to firgure out why this is the case, since the jboss.net
testcase code was easy to understand, so I may have missed something
simple...
This may work for simple cases, but once you declare additional data
structures and serializers, it becomes very hairy on the client side,
otherwise.
Well, for my purposes, I don't intend on sending complex Object graphs
over the wire. I also think that the Bean Serializer should be sufficient
for my purposes. By may work, do you mean will work without errors for
simple cases, or probably won't work for any case, so don't even try it?
Is there a test case that demonstrates the technique (A B above) that
you reccommend? I would find this quite useful. If I have time, I'll try
to write one myself, if it doesn't already exist.
On code generation in general, I must admit that I have a bit of healthy
skepticism on the matter. In this example, the amount of client side code
required to use the deprecated technique totals no more than a few lines,
while the output of wsdl2java comprises multiple full-fledged classes. It
seems to me that, auto-generated or not, this compromises a significant
ramp-up in code maitennance costs.
Based on your experience, what makes code generation the way to go in this
case? Do you find the generated code reasonable, easy to maintain,
scalable, reliable, etc.?
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jung ,
Dr. Christoph
Sent: Tuesday, September 24, 2002 10:06 AM
To: '[EMAIL PROTECTED]'
Subject: AW: [JBoss-dev] writing a jboss.net (jmx.net?) client
Matt,
For getting the client-side invocations and stub classes right, we recommend
The following steps:
A) generate wsdl from the deployed web services.
B) generate stub classes from the wsdl using wsdl2java.
Using Axis/MbeanInvocationHandler lacks a lot of deployment information
(basically, The client-side of the web-service.xml) that we try to default
from java reflection.
This may work for simple cases, but once you declare additional data
structures and serializers, it becomes very hairy on the client side,
otherwise.
CGJ
-Ursprüngliche Nachricht-
Von: Matt Munz [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 20. September 2002 17:41
An: JBoss Developers Group
Betreff: [JBoss-dev] writing a jboss.net (jmx.net?) client
CGJ
[JBoss-dev] [ jboss-Bugs-600474 ] EJB Handles in jboss3.0 not Serializable
Bugs item #600474, was opened at 2002-08-26 14:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=600474group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Marcus Redeker (mredeker) Assigned to: Scott M Stark (starksm) Summary: EJB Handles in jboss3.0 not Serializable Initial Comment: Hi, I am sending an EJBHandle as serialized object from one webcontext to another. The deserialization does not work and I get an exception. This worked in Jboss2.4.x and not in JBoss3 (3.0.1) anymore. We have a really big application with more then 1 logins a day and would really like to put this on a clustered environment. URGENT!!! This is a snippet from the error: 11:32:08,379 ERROR [Engine] StandardManager[] IOException while loading persisted sessions: java.io.EOFException java.io.EOFException at java.io.DataInputStream.readUnsignedShort (DataInputStream.java:347) at java.io.ObjectInputStream$BlockDataInputStream.readUn signedShort(ObjectInputStream.java:2633) at java.io.ObjectInputStream$BlockDataInputStream.readUT F(ObjectInputStream.java:2689) at java.io.ObjectInputStream.readUTF (ObjectInputStream.java:989) at java.rmi.server.RemoteObject.readObject (RemoteObject.java:394) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -- Comment By: Scott M Stark (starksm) Date: 2002-09-25 08:55 Message: Logged In: YES user_id=175228 This has been fixed for the 3.0.3 and later release. -- Comment By: Scott M Stark (starksm) Date: 2002-09-09 14:36 Message: Logged In: YES user_id=175228 The problem is that you are serializing the handle and then transporting that back to the client rather than letting the transport layer do the serialization. This fails because the JRMPInvoker is not being replaced by its remote stub. The immeadiate workaround is to pass the handle back to the client and let the rmi transport layer handle the marshalling of the RMI object. I'll look at changing the marshalling of the JRMPInvokerProxy to handle this automatically. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=600474group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-601049 ] MarshalException in serializing Handle
Bugs item #601049, was opened at 2002-08-27 16:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=601049group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Yan Pujante (madonnax) Assigned to: Scott M Stark (starksm) Summary: MarshalException in serializing Handle Initial Comment: I have the following code: // userSession is stateful session bean Handle ser = userSession.getHandle(); ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(ser); this throws the following exception: 15:57:19,944 ERROR [STDERR] java.rmi.MarshalException: Invalid remote object 15:57:19,946 ERROR [STDERR] at java.rmi.server.RemoteObject.writeObject(RemoteObject.java:332) 15:57:19,948 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 15:57:19,950 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 15:57:19,951 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 15:57:19,952 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 15:57:19,953 ERROR [STDERR] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:780) 15:57:19,955 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1294) 15:57:19,956 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245) 15:57:19,957 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) 15:57:19,961 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) 15:57:19,962 ERROR [STDERR] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.writeExternal(JRMPInvokerProxy.java:149) 15:57:19,963 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1265) 15:57:19,965 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1243) 15:57:19,966 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) 15:57:19,967 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330) 15:57:20,118 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302) 15:57:20,119 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245) 15:57:20,120 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) 15:57:20,121 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) A javax.ejb.Handle is supposed to be serializable so this should work. OS: Solaris 8 JDK 1.4.0_01 jboss: jboss-3.0.1RC1_tomcat-4.0.4 -- Comment By: Scott M Stark (starksm) Date: 2002-09-25 08:53 Message: Logged In: YES user_id=175228 Fixed for 3.0.3+ releases -- Comment By: Sandra Schmidt (sandresen) Date: 2002-09-24 23:40 Message: Logged In: YES user_id=617171 My problem is similar to yours. I tried to save the RemoteInterfaceHandle of a Stateful Session Bean in HttpSession with the same errormessage as a result. javax.ejb.Handle is an Interface, so what really is stored in the session is the implementation of that interface. I found out that org.jboss.proxy.ejb.handle.StatefulHandleImpl which implements javax.ejb.Handle contains an instance of org.jboss.invocation.Invoker which seems to be not serializable (respectively the class that implements the invoker- interface: org.jboss.invocation.jrmp.interfaces.JRMPInvokerPr oxy). Don`t know, if that helps or if that is the root cause of the error but I hope that something about this problem is done or at least a workaround is presented. OS: Windows XP JDK 1.4.0 with JBoss 3.0.2_tomcat 4.0.4 -- Comment By: Bernd Zeitler (frito) Date: 2002-08-30 03:55 Message: Logged In: YES user_id=603154 I did encounter the same difficulties. The handle of a SSB you obtain in a java application is serializable, while the handle you obtain inside JBoss is not. OS: W2K JDK 1.4.0_01 with JBoss 3.0.0_tomcat-4.0.3, JBoss 3.0.1_tomcat-4.0.4, JBoss 3.0.2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=601049group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED]
Re: [JBoss-dev] sources for hsqldb
onsdagen den 25 september 2002 kl 14.53 skrev Michael Bartmann: I find the hsqldb.jar under thirdparty. But it contains classes not in the release I obtained from the orig. HSQLDB-Project. I need the sources to find the reason for a thread leak, especially org.hsqldb.Embedded_Server which I find in the jboss's version of hsqldb.jar. Source is here : http://sourceforge.net/tracker/index.php?func=detailaid=533296group_id=23316; atid=378133 Notice : We start a instance of org.hsqldb.Server that has connection pooling of its own. That is probably the threads You se ? ... /peter_f PS: Also check out : http://sourceforge.net/tracker/index.php?func=detailaid=587623group_id=22866; atid=376687 for a way to use hsqldb inside jboss without a instance of org.hsqldb.Server class. :DS --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [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 gen-src-jdbc2: gen-src-jdbc3: [echo] generating sources for JDBC3 compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/server/output/classes [javac] Compiling 550 source files to /disk/orig/home/lubega/jbossro/jboss-all/server/output/classes /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:11: warning: java.security.Identity in java.security has been deprecated import java.security.Identity; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:243: warning: java.security.Identity in java.security has been deprecated public Identity getCallerIdentity() ^ /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) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:12: warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated import com.sun.net.ssl.KeyManagerFactory; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:13: warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated import com.sun.net.ssl.TrustManagerFactory; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:32: warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated public KeyManagerFactory getKeyManagerFactory() throws SecurityException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:38: warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated public TrustManagerFactory getTrustManagerFactory() throws SecurityException; ^ /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) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/invocation/jrmp/interfaces/JRMPInvokerProxy.java:163: cannot resolve symbol symbol : class RemoteStub location: class org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy if( remoteInvoker instanceof RemoteStub ) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/invocation/jrmp/interfaces/JRMPInvokerProxy.java:169: cannot resolve symbol symbol : variable RemoteObject location: class org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy Object replacement = RemoteObject.toStub(remoteInvoker); ^ 2 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 24 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608807 ] getCallerPrincipal() does not work
Bugs item #608807, was opened at 2002-09-13 01:47
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=608807group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Christen (tgdchmi2)
Assigned to: Scott M Stark (starksm)
Summary: getCallerPrincipal() does not work
Initial Comment:
Hi
We have a problem with the security in JBoss 3.0.0 and 3.0.2.
java full version J2RE 1.3.0 IBM build cx130-20010925
I already searched the WEB and the forum, but didn't found any
solution there.
The problem only occurs with a Java Client running outside the server
JVM.
(If we use servlets running in the same JVM as JBoss it works really
fine.)
If we use the method 'context.getCallerPrincipal()' inside the
ejbCreate()
method of a Session Bean (Stateful or Stateless) we get an
Exception on the server:
java.lang.IllegalStateException: No security context set
at
org.jboss.ejb.EnterpriseContext$EJBContextImpl.getCallerPrincipal(EnterpriseContext.java:248)
at
com.swisscom.swissbill.ejb.session.UserSessionBOBean.ejbCreate(Unknown
Source)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.createSession(StatefulSessionFilePersistenceManager.java:163)
at
org.jboss.ejb.StatefulSessionContainer.createHome(StatefulSessionContainer.java:441)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invokeHome(StatefulSessionContainer.java:756)
at
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:104)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:215)
at
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invokeHome(StatefulSessionInstanceInterceptor.java:128)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:98)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:52)
at
org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:109)
at
org.jboss.ejb.StatefulSessionContainer.invokeHome(StatefulSessionContainer.java:368)
at org.jboss.ejb.Container.invoke(Container.java:726)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:362)
at java.lang.reflect.Method.invoke(Native Method)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
at sun.rmi.transport.Transport$1.run(Transport.java:152)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:148)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706)
at java.lang.Thread.run(Thread.java:484)
The interesting point is, that the method 'context.getCallerPrincipal()'
works fine if I call the
create method twice:
UserSessionBO userSessionBO = null;
try {
userSessionBO = userSessionBOHome.create();
} catch (Exception ex) {
// we have to do this twice, because jboss is broken:
getCallerPrincipal() works after the 2nd call only
userSessionBO = userSessionBOHome.create();
}
The first call leads to the Exception above, and the second call works
fine.
My Session Bean:
public class UserSessionBOBean extends SwissBillSessionBean {
public void ejbCreate()
throws Exception {
try {
try {
dto.setUserId(context.getCallerPrincipal().getName());
} catch (Exception ex) {
dto = null;
throw new InternalServerException(LEVEL_ERROR, Could
not determine the userId. SecurityContext is probably not set.);
}
tracer.info(Creating a new UserSession for user:
'+dto.getUserId()+'.);
If I use context.getCallerPrincipal() inside a 'normal' method (not
ejbCreate) it works really fine, thus I think we don't do anything
wrong...
The EJB2.0 Specification defines that it should be possible to get the
callerPrincipal from inside the ejbCreate method.
So I think this is a bug in JBoss!?!
Thanx
--
Comment By: Scott M Stark (starksm)
Date: 2002-09-25 09:58
Message:
Logged In: YES
user_id=175228
Only stateful session beans are allowed to call
Re: [JBoss-dev] sources for hsqldb
viktor wrote: onsdagen den 25 september 2002 kl 14.53 skrev Michael Bartmann: I find the hsqldb.jar under thirdparty. But it contains classes not in the release I obtained from the orig. HSQLDB-Project. I need the sources to find the reason for a thread leak, especially org.hsqldb.Embedded_Server which I find in the jboss's version of hsqldb.jar. Source is here : http://sourceforge.net/tracker/index.php?func=detailaid=533296group_id=23316atid=378133 Notice : We start a instance of org.hsqldb.Server that has connection pooling of its own. That is probably the threads You se ? ... I get two threads each time, one of which is probably never started and not garbage collected due to a bug/feature of java jdk. Such processes increment ThreadGroup.activeCount() but don't show up when calling ThreadGroup.enumerate(). I have some 4000 such threads on a machine where only 80 are running. Cause they are never started it is more a memory leak than a thread leak... Thanks, Michael Bartmann /peter_f PS: Also check out : http://sourceforge.net/tracker/index.php?func=detailaid=587623group_id=22866atid=376687 for a way to use hsqldb inside jboss without a instance of org.hsqldb.Server class. :DS --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-603959 ] 3.0.2 farm-service.xml new attribute?
Bugs item #603959, was opened at 2002-09-03 05:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=603959group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 8 Submitted By: Dirk Vleugels (vleugels) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0.2 farm-service.xml new attribute? Initial Comment: Hi, i use the following farm-service.xml in 3.0.1 which works nicely (Solaris 2.8, Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode) server classpath codebase=lib archives=jbossha.jar/ mbean code=org.jboss.ha.framework.server.FarmMemberService name=jboss:service=FarmMember,partition=IPVPartition dependsjboss:service=IPVPartition/depends attribute name=PartitionNameIPVPartition/attribute attribute name=ScannerNamejboss.deployment:type=DeploymentScanner,flavor=URL/attribute /mbean /server using the same file in 3.0.2 yields this exception: 19:40:30,467 WARN [ServiceController] Problem creating service jboss:service=FarmMember,partition=IPVPartition org.jboss.system.MissingAttributeException: Missing attribute 'Deployer' at org.jboss.deployment.scanner.AbstractDeploymentScanner.createService(AbstractDeploymentScanner.java:249) at org.jboss.ha.framework.server.FarmMemberService.createService(FarmMemberService.java:113) I can't find anything in the ChangeLog / Documentation (AllSubscription) nor the forums Regards, Dirk -- Comment By: Scott M Stark (starksm) Date: 2002-09-25 10:27 Message: Logged In: YES user_id=175228 You need a depends element like the following: depends optional-attribute- name=Deployerjboss.system:service=MainDeployer/depe nds The 3.0.2 change notes have been updated with this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=603959group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-614116 ] Oracle XA pooling/repeated rollback
Bugs item #614116, was opened at 2002-09-24 16:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Oracle XA pooling/repeated rollback
Initial Comment:
I've been trying to isolate some problems I've been
having with transaction roll-backs and message-driven
beans. Basically, when a transaction is rolled-back
a number of times in the onMessage() body
(by calling MessageDrivenContext.setRollbackOnly()
5-10 times in succession),
the message is re-delivered to the MDB, but the Oracle
Connection is no longer in a good state.
This problem manifests itself when using a very small
connection pool (say 1-5) connections.
Example code snippet:
public void onMessage(javax.jms.Message jmsMessage)
{
Connection c = null;
try {
TextMessage tm = (TextMessage)jmsMessage;
String text = tm.getText();
c = ds.getConnection();
PreparedStatement s = c.prepareStatement(insert into test values (?));
s.setString(1, text);
s.executeUpdate();
mdc.setRollbackOnly();
} catch (Exception e) {
throw new EJBException(e);
} finally {
if (c != null) {
try { c.close(); }
catch (Exception e) {
e.printStackTrace();
}
}
First I see it works for a few times. It rolls-back successfully
about 5 or 6 times. Then, for no reason, I see:
15:50:44,922 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.delistResource(TxCapsule.java:579)
at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:92)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.delist(XATxConnectionManager.java:284)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.connectionClosed(XATxConnectionManager.java:331)
at
org.jboss.resource.adapter.jdbc.BaseManagedConnection.fireConnectionEvent(BaseManagedConnection.java:152)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.fireConnectionEvent(XAManagedConnection.java:215)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection$1.connectionClosed(XAManagedConnection.java:127)
at
oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:482)
at
oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:445)
at oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:2900)
at oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1418)
at com.proteusmobile.smx.AMDB.onMessage(AMDB.java:140)
Later:
15:50:44,929 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1312)
at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:440)
at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:83)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:301)
at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:603)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:417)
at org.jboss.mq.SpySession.run(SpySession.java:259)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655)
at java.lang.Thread.run(Thread.java:479)
And then, I can no longer get a connection:
15:50:44,971 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//5,
BranchQual=] errorCode=XAER_PROTO
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.disallowLocalTxnMode(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:153)
at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:679)
at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:102)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:262)
at
Re: [JBoss-dev] sources for hsqldb (LEAK FOUND)
Wow, now i see the leak! Embedded_ServerConnection extends Thread == but you do: Socket s = serverSocket.accept(); Embedded_ServerConnection c = new Embedded_ServerConnection(s, this); === Thread thread = new Thread(c); = thread.start(); So you got two instances of Thread, only one of which is started, with the inner one only playing the role of a runnable! Afterward closing you loose every reference to the inner (never started) thread, and the java jvm, due to a bug/feature never garbage-collects it (and its socket?). If there is no other usage of Embedded_ServerConnection we could simply let it implement Runnable instead of extending Thread, or otherwise not encapsulate it in a Thread afterwards. What is the best way to change the codebase? Another patch for hsqldb? Regards, Michael --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-594978 ] default page-size
Bugs item #594978, was opened at 2002-08-14 04:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=594978group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Andreas Billmann (frosch95) Assigned to: Dain Sundstrom (dsundstrom) Summary: default page-size Initial Comment: Hi, I need to use the page-size and I thought setting the page-size to 4 in the standardjbosscmp-jdbc.xml defaults ... read-ahead strategyon-load/strategy page-size4/page-size eager-load-group*/eager-load-group /read-ahead .. /defaults will cause the following sql statement for each kind of select: SELECT id,name FROM customerejb WHERE (id=1) OR (id=2) OR (id=3) OR (id=4) but instead the select statement is SELECT id,name FROM customerejb WHERE (id=1) OR (id=2) OR (id=3) OR (id=4) OR (id=5) OR (id=6) OR (id=7) OR (id=8) OR (id=9) OR (id=10) OR (id=11) OR (id=12) OR (id=13) OR (id=14) OR (id=15) OR (id=16) OR (id=17) OR (id=18) OR (id=19) OR (id=20) OR (id=21) OR (id=22) OR (id=23) OR (id=24) OR (id=25) OR (id=26) OR (id=27) OR (id=28) OR (id=29) OR (id=30) OR (id=31) OR (id=32) OR (id=33) OR (id=34) OR (id=35) OR (id=36) OR (id=37) OR (id=38) OR (id=39) OR (id=40) OR (id=41) OR (id=42) OR (id=43) OR (id=44) OR (id=45) OR (id=46) OR (id=47) OR (id=48) OR (id=49) OR (id=50) OR (id=51) OR (id=52) OR (id=53) OR (id=54) OR (id=55) OR (id=56) OR (id=57) OR (id=58) OR (id=59) OR (id=60) OR (id=61) OR (id=62) OR (id=63) OR (id=64) OR (id=65) OR (id=66) OR (id=67) OR (id=68) OR (id=69) OR (id=70) OR (id=71) OR (id=72) OR (id=73) OR (id=74) OR (id=75) I thought changing the default section will change the strategy for all the find methods. Should in JDBCReadAheadMetaData the default value not be overwritten if there is a new value in the standardjbosscmp-jdbc.xml default section? And I tried to use an EJB specific jbosscmp-jdbc.xml with readahead-values for the EJBs, but this doesn' t work either. The files are read in correctly, I logged the constructor calls in the JDBCReadAheadMetaData class, and every xml is parsed and a new JDBCReadAheadMetaData instance is created. But for all the findermethods the JDBCQueryMetaDataFactory.createJDBCQueryMetaData(QueryMetaData queryData) method is used and this one uses the JDBCQlQueryMetaData(QueryMetaData queryMetaData, Method method) constructor which uses JDBCReadAheadMetaData.DEFAULT as readahead value and this one is the fix value in the class and not a value read in from an xml file. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-25 13:40 Message: Logged In: YES user_id=251431 Fixed in Branch_3_0, Branch_3_2, and HEAD. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=594978group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-614116 ] Oracle XA pooling/repeated rollback
Bugs item #614116, was opened at 2002-09-24 19:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Oracle XA pooling/repeated rollback
Initial Comment:
I've been trying to isolate some problems I've been
having with transaction roll-backs and message-driven
beans. Basically, when a transaction is rolled-back
a number of times in the onMessage() body
(by calling MessageDrivenContext.setRollbackOnly()
5-10 times in succession),
the message is re-delivered to the MDB, but the Oracle
Connection is no longer in a good state.
This problem manifests itself when using a very small
connection pool (say 1-5) connections.
Example code snippet:
public void onMessage(javax.jms.Message jmsMessage)
{
Connection c = null;
try {
TextMessage tm = (TextMessage)jmsMessage;
String text = tm.getText();
c = ds.getConnection();
PreparedStatement s = c.prepareStatement(insert into test values (?));
s.setString(1, text);
s.executeUpdate();
mdc.setRollbackOnly();
} catch (Exception e) {
throw new EJBException(e);
} finally {
if (c != null) {
try { c.close(); }
catch (Exception e) {
e.printStackTrace();
}
}
First I see it works for a few times. It rolls-back successfully
about 5 or 6 times. Then, for no reason, I see:
15:50:44,922 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.delistResource(TxCapsule.java:579)
at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:92)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.delist(XATxConnectionManager.java:284)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.connectionClosed(XATxConnectionManager.java:331)
at
org.jboss.resource.adapter.jdbc.BaseManagedConnection.fireConnectionEvent(BaseManagedConnection.java:152)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.fireConnectionEvent(XAManagedConnection.java:215)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection$1.connectionClosed(XAManagedConnection.java:127)
at
oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:482)
at
oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:445)
at oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:2900)
at oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1418)
at com.proteusmobile.smx.AMDB.onMessage(AMDB.java:140)
Later:
15:50:44,929 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1312)
at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:440)
at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:83)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:301)
at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:603)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:417)
at org.jboss.mq.SpySession.run(SpySession.java:259)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655)
at java.lang.Thread.run(Thread.java:479)
And then, I can no longer get a connection:
15:50:44,971 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//5,
BranchQual=] errorCode=XAER_PROTO
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.disallowLocalTxnMode(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:153)
at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:679)
at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:102)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:262)
at
Re: [JBoss-dev] change in oracle-service.xml in HEAD
David Jencks wrote: On 2002.09.24 21:11:36 -0400 Emerson Cargnin - SICREDI Serviços wrote: David Jencks wrote: Yes. is there any reason for that? this question is becouse that this kind of change generates a lot of trouble (and questions to jboss-user list) when upgrading the server. Putting the jndiname in the RARDeployment mbean was a mistake, and I wanted to correct it sooner rather than later. Future versions of adapter deployment will deploy the ManagedConnectionFactory instance directly as an xmbean without needing a RARDeployment wrapper. To do this, only ManagedConnectionFactory methods can be used on what is now the RARDeployment. I strongly suggest you use the *-ds.xml files instedad of the *-service.xml files for datasource setup in 3.2 and head. ok, the exemple file in cvs should be changed too, I suppose. ??? I just double checked the oracle and oracle xa example files in 3.2 and head and they are correct. When I made the change I was pretty careful to change all the examples at the same time. i meaned the names of the files (*-ds.xml) david jencks david jencks On 2002.09.24 18:14:24 -0400 Emerson Cargnin - SICREDI Serviços wrote: I'm testing some code against HEAD and I saw that there's some changes at oracle-service.xml format. did the attribute name=JndiNameOracleDS/attribute attribute was moved out of the mbean code=org.jboss.resource.connectionmanager.RARDeployment... tag??? -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] sources for hsqldb (LEAK FOUND)
onsdagen den 25 september 2002 kl 20.43 skrev Michael Bartmann: What is the best way to change the codebase? Another patch for hsqldb? Commit something that works optimised ... is the best way... After running the testsuit that is ... :-) ... /peter_f PS: test and debug hsqldb 1.7.0 integration would be optimal :DS --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-607213 ] Read-Only Entity Bean
Bugs item #607213, was opened at 2002-09-10 04:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607213group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: vishal (attachvishal) Assigned to: Dain Sundstrom (dsundstrom) Summary: Read-Only Entity Bean Initial Comment: I am using jboss3.0.2 and i defined my entity bean as read-only in jbosscmp-jdbc.xml.It looks like this entity ejb- nameuk.co.isesolutions.apps.ccd.customer.entity.Customer/ejb- name table-nameCNCUSTOMER/table-name [b]read-onlytrue/read-only read-time-out1000/read- time-out[/b] cmp-field field- namecnCustomer/field-name column- nameCNCUSTOMER/column-name sql- typeNUMBER(12)/sql-type /cmp-field cmp- field field-nameu_Version/field-name column- nameU_VERSION/column-name sql- typeVARCHAR2(1)/sql-type /cmp-field ... cmp-field field- namecnaccom_Typ/field-name column- nameACCOM_TYP/column-name !--read- onlytrue/read-only read-time-out1000/read-time-out-- sql-typeNUMBER(12)/sql-type /cmp-field /entity and in Session bean i looked for Customer entity bean something like this Customer customer = getCustomerHome(CustomerHome.class).findByPrimaryKey(new CustomerPK(id)); customerVO = customer.showCustomerDetails(); /* the Below line should throw EJBException but container allows me update */ customer.setCnaccom_Typ(new Long(213)); At the jboss trace i noticed this 09:54:13,937 DEBUG [findByPrimaryKey] Executing SQL: SELECT CNCUSTOMER FROM CNCUSTOMER WHERE CNCUSTOMER=? 09:54:13,968 DEBUG [Customer] Executing SQL: SELECT CNORIGIN, SURNAME, CNORIGIN, FORENAME, DOB_DAT, ACTIVE_FLG FROM CNCUSTOMER WHERE (CNCUSTOMER=?) [b]09:54:14,875 DEBUG [Customer] Executing SQL: UPDATE CNCUSTOMER SET ACCOM_TYP=? WHERE CNCUSTOMER=? 09:54:14,890 DEBUG [Customer] Rows affected = 1[/b] -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-25 15:01 Message: Logged In: YES user_id=251431 Fixed in Branch_3_0, Branch_3_2 and HEAD. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=607213group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Sorry to post to this list but I'm currently dealing with this issue in
my own project and thought it would be appropriate to comment. Also,
I'm not sure where to post any buildmagic related questions or if there
is such a place to do so.
We've recently switched to buildmagic. I've more recently been setting
up testsuites just as you are suggesting here (where specific modules
have their own testsuite sub-module). We are currently intending to
implement a master testsuite module to run the other testsuites and to
perhaps contain cross module tests. So far, things are going ok but
there are some issues I'm trying to figure out.
Probably the biggest annoyance I have with using a sub-module is that
the ${project.root} property within the sub-module ends up including the
module above it instead of being the actual project root, so I have to
define my own local ${project.root.local} property in each sub-module.
To illustrate:
from a first level module:
${project.root}=/home/ssayles/src/myProject
from within a sub-module:
${project.root}=/home/ssayles/src/myProject/myModule
Is it possible to get this value to remain the real project root?
Perhaps I'm missing something?
Also, one of my thoughts is that we should raise developer awareness
about the associated tests for a module. In other words, if they change
something in the code which breaks the tests for that module, this
should be readily apparent. Of course, this will happen when you
execute the main build if you have your module/testsuite listsed as a
module. But I find that I will build often from within a specific
module that I'm working on and don't want to execute the main build
because it takes too long. I'm pretty new to buildmagic, so please
correct me if I'm mistaken in my approach. Based on this, I see two
probable scenarios for structuring the build for the sub-module
testsuites:
1. Add them as modules in the main build and continue to use the main
build.
e.g. modules=moduleFoo/testsuite
This seems to fit appropriately within buildmagic
2. Force the integration of the module build with the associated
testsuite. In other words, have build targets within the module call
correlating targets in the testsuite sub-module. This does not seem to
fit within the buildmagic way of doing things (to me), but it could
work.
I like option 2 because when I run moduleFoo/build.sh, I know
immediately if I've broken a test compilation. But I'm not sure if we
should set things up like this. Any suggestions?
Thanks.
Scott
On Thu, 2002-09-19 at 20:48, Jason Dillon wrote:
So are you suggesting that there be, more or less, a build file per
testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then
the
testsuite/build.xml calls each of them?
No, I am suggesting there be a testsuite in each module.
build/build.xml would be configured to recurse into them collect the
results for a final report. Or you could just run the module testsuite
for the bits you are working on.
Or if you are just interested in the integration tests, you can run
jboss/testsuite. Or if you just care about how jboss/cluster works, you
might run the cluster and testsuite module's tests target.
I think that would accomplish essentially the same thing I was
suggesting
with the generic targets for run xdoclet in one directory and build
jars from one directory suggestion.
Hrm, you gonna have to explain this again... I don't understand what ya
mean here. Sorry =]
--jason
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] sources for hsqldb (LEAK FOUND)
viktor wrote: onsdagen den 25 september 2002 kl 20.43 skrev Michael Bartmann: What is the best way to change the codebase? Another patch for hsqldb? Commit something that works optimised ... is the best way... After running the testsuit that is ... :-) ... /peter_f PS: test and debug hsqldb 1.7.0 integration would be optimal :DS My question concerning best way was more a technical one; there are two sf.net projects involved. The build process of the patched hsqldb jar is not part of the jboss build. A possible answer might be: 0) test... 1) post patch to hsqldb (as source) 2) build the modified jar in your garage (as binary) 3) commit the jar to Branch_X of jboss cvs Regards, Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 25-September-2002
Number of tests run: 934
Successful tests: 928
Errors:2
Failures: 4
[time of test: 25 September 2002 13:9 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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] sources for hsqldb (LEAK FOUND)
onsdagen den 25 september 2002 kl 22.17 skrev Michael Bartmann: A possible answer might be: 0) test... 1) post patch to hsqldb (as source) 2) build the modified jar in your garage (as binary) 3) commit the jar to Branch_X of jboss cvs Just Do IT(TM) comes to mind ... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] sources for hsqldb (LEAK FOUND)
Do we still need the hacked version with the latest release of HSQLDB? If not lets drop the hacked version and just integrate what they release. If not, then lets get a fix into the HSQLDB sources so they are more embeddable. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Michael Bartmann Sent: Wednesday, September 25, 2002 1:18 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] sources for hsqldb (LEAK FOUND) viktor wrote: onsdagen den 25 september 2002 kl 20.43 skrev Michael Bartmann: What is the best way to change the codebase? Another patch for hsqldb? Commit something that works optimised ... is the best way... After running the testsuit that is ... :-) ... /peter_f PS: test and debug hsqldb 1.7.0 integration would be optimal :DS My question concerning best way was more a technical one; there are two sf.net projects involved. The build process of the patched hsqldb jar is not part of the jboss build. A possible answer might be: 0) test... 1) post patch to hsqldb (as source) 2) build the modified jar in your garage (as binary) 3) commit the jar to Branch_X of jboss cvs Regards, Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] sources for hsqldb (LEAK FOUND)
onsdagen den 25 september 2002 kl 23.02 skrev Jason Dillon: Do we still need the hacked version with the latest release of HSQLDB? If not lets drop the hacked version and just integrate what they release. If not, then lets get a fix into the HSQLDB sources so they are more embeddable. They have a new no_system_exit flag inspired by us in the new 1.7.x version --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608202 ] EJBQL fails to compile
Bugs item #608202, was opened at 2002-09-12 00:30
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=608202group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
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:
query
query-method
method-nameejbSelectCargoValue/method-name
method-params
method-parampacket.interfaces.PacketEntityLocal/method-param
method-paramjava.lang.String/method-param
/method-params
/query-method
ejb-ql[CDATA[SELECT c.value FROM PacketEntity p, IN
(p.cargoes) AS c WHERE p = ?1 AND c.name = ?2]]/ejb-ql
/query
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.init(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: Dain Sundstrom (dsundstrom)
Date: 2002-09-25 16:46
Message:
Logged In: YES
user_id=251431
Fixed in Branch_3_0, Branch_3_2, and HEAD
The problem was ASTSelect would visit the ASTPath and that
code does not support value classes, as it was mainly
written for the where clause. The fix is to simply call
getColumnNames clause directly from the ASTSelect visit.
--
Comment By: Cory Prowse (cosmic)
Date: 2002-09-17 22: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-16 15: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-12 20: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-12 12: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=detailatid=376685aid=608202group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] SUBMITTING DOCUMENTATION PLEASE READ
Guys, first of all sorry for the lack of input in the last days, NYC took a lot of time and I have been out most of the week. JBoss Group grows fast and I need to be everywhere at once, if only I could clone myself :) OK here is the point: we need to be sure our free and for-pay documentations remain up to date. Too many new features make it in the codebase WITHOUT any documentation attached to it and dissapear in the noise for lack of visibility. I want to change that once and for all, I will ask that as you submit new code you also submit the JUnit tests if you have them as the documentation. The documentation can come in 2 sets. The documentation should include a beginner getting started couple of paragraph, explaining the feature and how to use it for the getting started book. If your feature is complex enough, it should also come with FOR-PAY pages. These pages will be included in the for-pay documentation of JBoss and the author compensated based on the revenues. You don't need to produce a booklet (few stuff like the CMP stuff is big enough to warrant a booklet). Is it clear? Please follow these guidelines for the new submissions it is the only way your features will be used at all and it is also a simple way to make some easy money with us. regards marc f xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss3.2-Tomcat4.1.10
I've put together a working version of JBoss3.0.2-Tomcat4.1.12 (using the Digester class instead of XmlMapper). Everything works fine (a new tomcat4-service.jar gets built), except that I'm having trouble with deployment. When a war contains a jar file, I get the following exception: java.net.MalformedURLException: invalid url: jndi:/localhost/struts-documentation/WEB-INF/lib/jakarta-oro.jar!/ (java.net.MalformedURLException: unknown protocol: jndi) at java.net.URL.init(URL.java:613) at java.net.URL.init(URL.java:476) at java.net.URL.init(URL.java:425) at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java: 902) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868 ) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.j ava:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSu pport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493 ) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.ja va:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.jboss.web.catalina.EmbeddedCatalinaServiceSX.createWebContext(Embedd edCatalinaServiceSX.java:427) at org.jboss.web.catalina.EmbeddedCatalinaServiceSX.performDeploy(EmbeddedC atalinaServiceSX.java:302) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:300) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:802) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDi spatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentSc anner.java:427) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeplo ymentScanner.java:648) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScan ner.java:499) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abst ractDeploymentScanner.java:261) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:164) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDi spatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController .java:967) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:396) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDi spatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:249) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:802) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:564) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDi spatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at
[JBoss-dev] jboss daily test 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 [execmodules] t2.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:75: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:129: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/MassiveTest.java:133: warning: stop() in java.lang.Thread has been deprecated [execmodules] tf.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:74: warning: stop() in java.lang.Thread has been deprecated [execmodules] t1.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/jbossmq/stress/QueueTest.java:116: warning: stop() in java.lang.Thread has been deprecated [execmodules] t2.stop(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/security/test/EJBSpecUnitTestCase.java:102: cannot resolve symbol [execmodules] symbol : class StatefulSessionHome [execmodules] location: class org.jboss.test.security.test.EJBSpecUnitTestCase [execmodules] obj = PortableRemoteObject.narrow(obj, StatefulSessionHome.class); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/security/test/EJBSpecUnitTestCase.java:103: cannot resolve symbol [execmodules] symbol : class StatefulSessionHome [execmodules] location: class org.jboss.test.security.test.EJBSpecUnitTestCase [execmodules] StatefulSessionHome home = (StatefulSessionHome) obj; [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/security/test/EJBSpecUnitTestCase.java:103: cannot resolve symbol [execmodules] symbol : class StatefulSessionHome [execmodules] location: class org.jboss.test.security.test.EJBSpecUnitTestCase [execmodules] StatefulSessionHome home = (StatefulSessionHome) obj; [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/security/test/EJBSpecUnitTestCase.java:106: cannot resolve symbol [execmodules] symbol : class StatefulSession [execmodules] location: class org.jboss.test.security.test.EJBSpecUnitTestCase [execmodules] StatefulSession bean = home.create(testStatefulCreateCaller); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/security/test/LoginModulesUnitTestCase.java:285: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j.Category has been deprecated [execmodules] root.setPriority(XLevel.TRACE); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/security/test/XMLLoginModulesUnitTestCase.java:41: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j.Category has been deprecated [execmodules] root.setPriority(XLevel.TRACE); [execmodules] ^ [execmodules] 4 errors [execmodules] 23 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/testsuite/build.xml:899: Compile failed; see the compiler error output for details. Total time: 2 minutes 18 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-526696 ] session.recover() doesn't work
Bugs item #526696, was opened at 2002-03-06 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=526696group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kelly McTiernan (kellymct) Assigned to: Scott M Stark (starksm) Summary: session.recover() doesn't work Initial Comment: All operating systems. Any version of Java. N/A. Call session.recover(). According to the JMS spec, a call to session.recover() from a transacted session should return an IllegalStateException. This it does, with the message: The session is trasacted. When called with a non-transacted session, however, recover still throws an IllegalStateException, this time with the message: The session is not transacted. Looking into the code a little, it turns out that the recover() method does a check for the session being transacted, and throws the IllegalStateException with the second message if it is. Then it proceeds to call rollback(), which does a check for the session NOT being transacted, and throws the IllegalStateException with the second message if it's not. -- Comment By: Scott M Stark (starksm) Date: 2002-09-25 16:52 Message: Logged In: YES user_id=175228 A fix has been applied to 2.4 for the 2.4.10 release -- Comment By: Andreas Schaefer (schaefera) Date: 2002-07-21 19:26 Message: Logged In: YES user_id=70434 ATTENTION: the fix is only done for JBoss 3.0. -- Comment By: Andreas Schaefer (schaefera) Date: 2002-07-19 10:53 Message: Logged In: YES user_id=70434 HELP: could thesitesman or Seth send me the diff directly to [EMAIL PROTECTED]. Thanx otherwise I have to deal with all these line wraps. Andy -- Comment By: Andreas Schaefer (schaefera) Date: 2002-07-19 10:16 Message: Logged In: YES user_id=70434 ATTENTION: STOP THIS DISCUSSION HERE The bug reports are here to discuss a bug and only this bug. Any other discussion should go either in the JBoss Forum or the JBoss developer list. Andy -- Comment By: Seth Sites (thesitesman) Date: 2002-07-19 10:05 Message: Logged In: YES user_id=579275 the other problems that I see is that according to the spec are: 1)It [the session] retains messages it consumes until they have been acknowledged. From what I see, it loses its reference to the message as soon as it passes it on. The only messages that it has are ones that have not been consumed. We keep the session reference in the message, but do keep the message reference in the session. 2) With this option [Client ack], a client acknowledges a message by calling the messages acknowledge method. Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been delivered by its session. right now it only ack's the single message. another reason we need to have a reference to all unack'd messages in session. 3)My fix goes all the way back to the server to redeliver and that is not spec. Spec says the session should do it. My way you might not receive all of your messages if their are other listeners on board. But the spec cleary says all of your unacked messages that you had received. I will rework to fix both of these problems. I would like some input on whether to redeliver unacked messages when a client unsibscribes, closes connection or loses connection. According to spec, as long as you set JMSRedelivered the client should be aware that this message may have been delivered elsewhere and just not acked. -- Comment By: Seth Sites (thesitesman) Date: 2002-07-19 05:20 Message: Logged In: YES user_id=579275 upon reviewing the spec again for one of the other bugs, it looks like some other minor modifications are needed. The wording in the spec makes it seem that when any client who closes connection (willfully or not) with unack'd messages, those messages should get redelivered. pg 58 Closing a connection does NOT force an acknowledgement of client-acknowledged sessions. I would assume that these messages should be placed back into the queue immediately and not only when the server is restarted. -Seth -- Comment By: Seth Sites (thesitesman) Date: 2002-07-19 04:47 Message: Logged In: YES user_id=579275 This is my proposed fix for session.recover(). It also handles redelivery of messages that are still unacknowledged when a client's connection crashes. I have tested this code in HEAD and it also did not break any of the testsuite
RE: [JBoss-dev] SUBMITTING DOCUMENTATION PLEASE READ
I want to change that once and for all, I will ask that as you submit new code you also submit the JUnit tests if you have them as the documentation. The documentation can come This doesn't make sense. I mean, just like you have you junit test, submit doco Doco is not the junit obviously so the junit as doco doesn't make sense, yes I am still talking about word files for the documentation so that we can easily include them in our books. And I don't want this to degenerate in 'What format should we use for doco bla bla bla just gives us WORD documents and we will deal with them (text if you use linux) marc f in 2 sets. The documentation should include a beginner getting started couple of paragraph, explaining the feature and how to use it for the getting started book. If your feature is complex enough, it should also come with FOR-PAY pages. These pages will be included in the for-pay documentation of JBoss and the author compensated based on the revenues. You don't need to produce a booklet (few stuff like the CMP stuff is big enough to warrant a booklet). Is it clear? Please follow these guidelines for the new submissions it is the only way your features will be used at all and it is also a simple way to make some easy money with us. regards marc f xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-user] RE: [JBoss-dev] SUBMITTING DOCUMENTATION PLEASE READ
Whom should I send it? alex I want to change that once and for all, I will ask that as you submit new code you also submit the JUnit tests if you have them as the documentation. The documentation can come mf This doesn't make sense. I mean, just like you have you junit test, mf submit doco Doco is not the junit obviously so the junit as doco mf doesn't make sense, yes I am still talking about word files for the mf documentation so that we can easily include them in our books. mf And I don't want this to degenerate in 'What format should we use for mf doco bla bla bla just gives us WORD documents and we will deal with mf them (text if you use linux) mf marc f in 2 sets. The documentation should include a beginner getting started couple of paragraph, explaining the feature and how to use it for the getting started book. If your feature is complex enough, it should also come with FOR-PAY pages. These pages will be included in the for-pay documentation of JBoss and the author compensated based on the revenues. You don't need to produce a booklet (few stuff like the CMP stuff is big enough to warrant a booklet). Is it clear? Please follow these guidelines for the new submissions it is the only way your features will be used at all and it is also a simple way to make some easy money with us. regards marc f xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
