[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 19-February-2003
JBoss daily test results SUMMARY Number of tests run: 1105 Successful tests: 1099 Errors:6 Failures: 0 [time of test: 2003-02-20.06-24 GMT] [java.version: 1.4.1_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_01-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-02-20.06-24 for the junit report of this test. 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: SecurityUnitTestCase Test:runValidDynDurSub(org.jboss.test.jbossmq.test.SecurityUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute "persistPolicy" with value "Never" must have a value from the list "NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER ".; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute "persistPolicy" with value "Never" must have a value from the list "NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER ".)) - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: JSR77SpecUnitTestCase Test:testNavigation(org.jboss.test.management.test.JSR77SpecUnitTestCase) Type:error Exception: javax.management.InstanceNotFoundException Message: jboss.management.local:J2EEApplication=cts-v1cmp.ear,J2EEServer=Local,j2eeType=EJBModule,name=cts-v1cmp.jar is not registered. - Suite: HttpsUnitTestCase Test:testJSSE(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.net.BindException Message: Address already in use: JVM_Bind - Suite: SRPUnitTestCase Test:testEchoArgs(org.jboss.test.security.test.SRPUnitTestCase) Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-689860 ] Start and config patch
Patches item #689860, was opened at 2003-02-20 07:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=689860&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Gabriele Garuglieri (ggaru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Start and config patch
Initial Comment:
I work for a large account and I'm evaluating the
possibility to introduce Jboss for our internal
applications.
To help us managing Jboss installations I'd need some
little changes in its startup behaviour, so to obtain
something similar (slightly better) to what I already
do with BEA and Tomcat.
Here's what I need:
We have many applications logically divided in groups
and for each group we need a different server run via a
different unix user that must not have write permission
to the location where Jboss is installed, but in the
same time many of them use common base libraries and
helper applications, so to avoid having the nightmare
of carrying around copies of Jboss libraries and
application libraries and ear's and war's I'd like to
factorize anything common in a single place and in the
same time keep at minimum the configuration effort.
To obtain this, I thought to introduce (or
reintroduce?) the concept of Jboss distribution, i.e.
what is obtainded unpacking the downloaded zip file or
building the source and containing all the necessary to
startup a base server, and that of Jboss application
server environment that would need to contain only the
deploy, conf, db, log and tmp directories. The lib dir
would be needed only if this application server uses
some specialized libraries that cannot or must not be
factorized in a common place.
With this in mind I wrote a small patch that
corrects/add the following things:
· In Main the line command options are processed as
first action. This allows to set any System.property,
comprised jboss.home.dir and jboss.home.url from a
property file. As a side effect this allows to start
Jboss using run(.bat/.sh) from a distribution
installation bin dir, without the need to have it in
the jboss.home.dir.
· Few new System properties related to Jboss
distribution installation are introduced, in particular
jboss.dist.home.dir and jboss.dist.home.url that can
refere to read only Jboss installation. If none ot
these are initialized, nothing changes. If initialized,
the content of jboss.dist.home.url is used as base to
create jboss.dist.lib.url property. So the boot
libraries are looked for in the order from
jboss.lib.url (if the directory exists) and
jboss.dist.lib.url (nstallation dir)..
This means that if jboss.dist.lib.url contains a valid
URL pointing to jboss distribution lib dir, boot
libraries and extra libraries are searched from
jboss.lib.url and jboss.dist.lib.url in this order, so
there is no more the need to have lib directory into
jboss.home.dir and lib directory can be referred in a
unique read only place from any number of servers.
· SARDeployer now uses an ArrayList to hold the
classpaths built from elements into
service.xml files (in particular for jboss-service.xml
run to complete the boot phase). This means that if
multiple elements are present they are kept
in the order they are written and you can create a
hierarchical lib urls chain that allows for class override.
· SARDeployer now allows property substitution for
codebase and archives attributes of element
much the same way that URLDeploymentScanner does for
deploy URLs. This allows to keep most of all the
absolute location references into a single property file.
· As a side effect of the last two points if you have
configured jboss.dist.home and jboss.server.dist.name
to point to a valid distribution server model and you
add a last classpath line of the form:
you can omit the lib directory from within your
jboss.server.home.dir. This means that many servers can
refer to a single read only place for their server lib
directory.
· Again if you specify a first line like
${jboss.server.dist.home.url}deploy for of
you can factorize anything common system level that
needs to be deployed during the boot phase in a single
read only distribution deploy dir different from single
server deploy directory.
DISCLAIMER:
I have written the patch against the 3.0.6 source code
and since to help the coding I have imported the source
into a cvs repository in my notebook, all the Revision
numbers into the source files were screwed up. I added
a comment line in which I annotated the Revision number
of the each source file on which the patch apply.
Obviously the lines dealing with the comments
containing revision numbers must removed from the patch.
The patch file is the complete output from cvs diff.
I tested the changes only on the jetty version and for
sure not exaustively but the changes are so light I
don't think they should have obscure side effects.
I hope I didn't overlooked anything, since I'm still
fighting with burocracy to
[JBoss-dev] [ jboss-Bugs-689653 ] Dynamic Class Loading issue
Bugs item #689653, was opened at 2003-02-19 15:10
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
Category: JBossMX
Group: v3.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Muruga Chinnananchi (muruga)
>Assigned to: Scott M Stark (starksm)
Summary: Dynamic Class Loading issue
Initial Comment:
Problem Description:
Dynamically generated classes (while running jboss
server) that are placed under C:/classes/ directory
is not visible to the war file which is deployed
under server/default/deploy/ directory.
My Configuration:
--
Version: 3.2 RC 2.0 (with bundled Jetty)
Platform: Windows 2000
Jdk: 1.3.1_02
Steps to reproduce:
---
1. Create a classes directory under c:/
2. Add the classes directory to the conf/jboss-
service.xml
3. Start the jboss server in default mode ( run.bat)
4. Put the attached myapp.war file in the
default/deploy directory
5. Copy and Paste the following content in
MyClass.java and compile it and put it under
c:/classes directory.
package com.mycom;
public class MyClass
{
private String data;
public MyClass()
{
data = "f";
}
public String getData( )
{
return data;
}
}
6. Try invoking the MyApp war like below
http://localhost:8080/myapp/
7. You will see ClassDefNotFound printStackTrace
on the dos shell.
2003-02-19 14:32:46,078 WARN
[org.jboss.jbossweb] WARNING: Exception
for /myapp/
java.lang.NoClassDefFoundError:
com/mycom/MyClass
at java.lang.Class.newInstance0(Native
Method)
at java.lang.Class.newInstance
(Class.java:237)
at
org.apache.jasper.servlet.JspServletWrapper.getServl
et(JspServletWrapper.java:146)
at
org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:189)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at
org.apache.jasper.servlet.JspServlet.service
(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch
(Dispatcher.java:194)
at
org.mortbay.jetty.servlet.Dispatcher.forward
(Dispatcher.java:129)
at
org.mortbay.jetty.servlet.Default.handleGet
(Default.java:239)
at
org.mortbay.jetty.servlet.Default.service
(Default.java:153)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:553)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1656)
at
org.mortbay.jetty.servlet.WebApplicationContext.ha
ndle(WebApplicationContext.java:549)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1606)
at org.mortbay.http.HttpServer.service
(HttpServer.java:862)
at org.jboss.jetty.Jetty.service
(Jetty.java:497)
at
org.mortbay.http.HttpConnection.service
(HttpConnection.java:752)
at
org.mortbay.http.HttpConnection.handleNext
(HttpConnection.java:916)
at
org.mortbay.http.HttpConnection.handle
(HttpConnection.java:769)
at
org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:202)
at org.mortbay.util.ThreadedServer.handle
(ThreadedServer.java:289)
at
org.mortbay.util.ThreadPool$PoolThread.run
(ThreadPool.java:455)
--
>Comment By: Scott M Stark (starksm)
Date: 2003-02-19 22:52
Message:
Logged In: YES
user_id=175228
The only time this happens is if the class is not under the
classes directory when the war starts. If it is, this runs fine. If
the class is not there at startup and moved in latter this error
occurs.
Obviously the jsp compiler sees this class since a servlet is
being created, but the URLClassLoader has apparently
already determined that the directory does not contain the
class and this result is cached. This is not something we will
change anytime in the near future. Allowing classes to be
added is one thing that might be supported at some future
time, but its not a priority.
--
Comment By: Muruga Chinnananchi (muruga)
Date: 2003-02-19 15:27
Message:
Logged In: YES
user_id=81331
Here is the MyClass.java source file!
--
Comment By: Muruga Chinnananchi (muruga)
Date: 2003-02-19 15:25
Message:
Logged In: YES
user_id=81331
If you want you can just copy the attach
[JBoss-dev] [ jboss-Bugs-682618 ] xDoclet: xmbean generation does not match the DTD
Bugs item #682618, was opened at 2003-02-07 22:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682618&group_id=22866 Category: None Group: v4.0 Status: Open Resolution: None Priority: 7 Submitted By: Matthew Munz (mattmunz) Assigned to: David Jencks (d_jencks) Summary: xDoclet: xmbean generation does not match the DTD Initial Comment: I wasn't sure where to submit this-- if this is the wrong place, let me know... The XMBean XML generated by xDoclet does not fit the XMBean DTD. Essentially, the descriptors are written in the wrong order. Here are my xDoclet tags * @jmx.mbean * persistPolicy = "OnUpdate" * persistName = "Resource2-state.xml" * persistLocation = "D:/Matt/apelon/temporary/MBean-Repository" * display-name = "Resource #2 Test MBean" * name = "jboss.jmx.test:name=Resource2" * persistence-manager = "org.jboss.mx.persistence.XMLPersistenceManager" * @jboss.xmbean here's the xml generated by xDoclet and here's the parser error org.xml.sax.SAXParseException: The content of element type "descriptors" must match (persistence?,currencyTimeLimit?,state-action-on-update?,display-name?, default?,value?,persistence-manager?,descriptor*)". - Matt -- >Comment By: David Jencks (d_jencks) Date: 2003-02-20 05:21 Message: Logged In: YES user_id=60525 This is fixed in xdoclet cvs but not yet in our binary copy. I'll close this after updating our cvs binary copy. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682618&group_id=22866 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-673371 ] NoTxConnection named LocalTx...
Bugs item #673371, was opened at 2003-01-23 21:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=673371&group_id=22866 Category: JBossServer Group: CVS HEAD >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: David Jencks (d_jencks) Summary: NoTxConnection named LocalTx... Initial Comment: I deployed a jca-adapter and a mbi3-ds.xml file with the following content: eis/MBI3 MBI3 rm200 1408 0 1 360 The result is a ConnectionManager with a wrong name: [jca.mbi3.ManagedConnectionFactoryImpl.eis/MBI3.info] Bound connection factory for resource adapter for ConnectionManager 'jboss.jca:service=LocalTxCM,name=eis/MBI3 to JNDI name 'java:/eis/MBI3' LocalTx instead of NoTx ! -- >Comment By: David Jencks (d_jencks) Date: 2003-02-20 05:40 Message: Logged In: YES user_id=60525 fixed -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=673371&group_id=22866 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBeanProxy with JBoss Remoting
yes On Wed, 19 Feb 2003, Anatoly Akkerman wrote: > Hi, > > I don't know if this is obvious and I am treading old ground or makes > sense or not, but given that JMX remoting already works, if one creates > a Java proxy to an MBean via MBeanProxy and that Proxy instance gets > shipped through the Remoting infrastructure, wouldn't it make sense to > make the JMXInvocationHandler to push invocations on this proxy to the > original MBean through the Remoting pipe that it arrived through? This > would be useful if an invocation on an MBean returns such a proxy object > (say, this MBean is a Factory MBean for other MBeans but clients prefer > typed invocation on the factory) and now you want to invoke this factory > MBean remotely and still get meaningful objects back. > > -- Anatoly > --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MBeanProxy with JBoss Remoting
Hi, I don't know if this is obvious and I am treading old ground or makes sense or not, but given that JMX remoting already works, if one creates a Java proxy to an MBean via MBeanProxy and that Proxy instance gets shipped through the Remoting infrastructure, wouldn't it make sense to make the JMXInvocationHandler to push invocations on this proxy to the original MBean through the Remoting pipe that it arrived through? This would be useful if an invocation on an MBean returns such a proxy object (say, this MBean is a Factory MBean for other MBeans but clients prefer typed invocation on the factory) and now you want to invoke this factory MBean remotely and still get meaningful objects back. -- Anatoly --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-689653 ] Dynamic Class Loading issue
Bugs item #689653, was opened at 2003-02-19 23:10
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Muruga Chinnananchi (muruga)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic Class Loading issue
Initial Comment:
Problem Description:
Dynamically generated classes (while running jboss
server) that are placed under C:/classes/ directory
is not visible to the war file which is deployed
under server/default/deploy/ directory.
My Configuration:
--
Version: 3.2 RC 2.0 (with bundled Jetty)
Platform: Windows 2000
Jdk: 1.3.1_02
Steps to reproduce:
---
1. Create a classes directory under c:/
2. Add the classes directory to the conf/jboss-
service.xml
3. Start the jboss server in default mode ( run.bat)
4. Put the attached myapp.war file in the
default/deploy directory
5. Copy and Paste the following content in
MyClass.java and compile it and put it under
c:/classes directory.
package com.mycom;
public class MyClass
{
private String data;
public MyClass()
{
data = "f";
}
public String getData( )
{
return data;
}
}
6. Try invoking the MyApp war like below
http://localhost:8080/myapp/
7. You will see ClassDefNotFound printStackTrace
on the dos shell.
2003-02-19 14:32:46,078 WARN
[org.jboss.jbossweb] WARNING: Exception
for /myapp/
java.lang.NoClassDefFoundError:
com/mycom/MyClass
at java.lang.Class.newInstance0(Native
Method)
at java.lang.Class.newInstance
(Class.java:237)
at
org.apache.jasper.servlet.JspServletWrapper.getServl
et(JspServletWrapper.java:146)
at
org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:189)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at
org.apache.jasper.servlet.JspServlet.service
(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch
(Dispatcher.java:194)
at
org.mortbay.jetty.servlet.Dispatcher.forward
(Dispatcher.java:129)
at
org.mortbay.jetty.servlet.Default.handleGet
(Default.java:239)
at
org.mortbay.jetty.servlet.Default.service
(Default.java:153)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:553)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1656)
at
org.mortbay.jetty.servlet.WebApplicationContext.ha
ndle(WebApplicationContext.java:549)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1606)
at org.mortbay.http.HttpServer.service
(HttpServer.java:862)
at org.jboss.jetty.Jetty.service
(Jetty.java:497)
at
org.mortbay.http.HttpConnection.service
(HttpConnection.java:752)
at
org.mortbay.http.HttpConnection.handleNext
(HttpConnection.java:916)
at
org.mortbay.http.HttpConnection.handle
(HttpConnection.java:769)
at
org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:202)
at org.mortbay.util.ThreadedServer.handle
(ThreadedServer.java:289)
at
org.mortbay.util.ThreadPool$PoolThread.run
(ThreadPool.java:455)
--
>Comment By: Muruga Chinnananchi (muruga)
Date: 2003-02-19 23:27
Message:
Logged In: YES
user_id=81331
Here is the MyClass.java source file!
--
Comment By: Muruga Chinnananchi (muruga)
Date: 2003-02-19 23:25
Message:
Logged In: YES
user_id=81331
If you want you can just copy the attached
MyClass.class to your c:/classes directory.
--
Comment By: Muruga Chinnananchi (muruga)
Date: 2003-02-19 23:12
Message:
Logged In: YES
user_id=81331
Here is the attachment.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jbos
[JBoss-dev] [ jboss-Bugs-689653 ] Dynamic Class Loading issue
Bugs item #689653, was opened at 2003-02-19 23:10
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Muruga Chinnananchi (muruga)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic Class Loading issue
Initial Comment:
Problem Description:
Dynamically generated classes (while running jboss
server) that are placed under C:/classes/ directory
is not visible to the war file which is deployed
under server/default/deploy/ directory.
My Configuration:
--
Version: 3.2 RC 2.0 (with bundled Jetty)
Platform: Windows 2000
Jdk: 1.3.1_02
Steps to reproduce:
---
1. Create a classes directory under c:/
2. Add the classes directory to the conf/jboss-
service.xml
3. Start the jboss server in default mode ( run.bat)
4. Put the attached myapp.war file in the
default/deploy directory
5. Copy and Paste the following content in
MyClass.java and compile it and put it under
c:/classes directory.
package com.mycom;
public class MyClass
{
private String data;
public MyClass()
{
data = "f";
}
public String getData( )
{
return data;
}
}
6. Try invoking the MyApp war like below
http://localhost:8080/myapp/
7. You will see ClassDefNotFound printStackTrace
on the dos shell.
2003-02-19 14:32:46,078 WARN
[org.jboss.jbossweb] WARNING: Exception
for /myapp/
java.lang.NoClassDefFoundError:
com/mycom/MyClass
at java.lang.Class.newInstance0(Native
Method)
at java.lang.Class.newInstance
(Class.java:237)
at
org.apache.jasper.servlet.JspServletWrapper.getServl
et(JspServletWrapper.java:146)
at
org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:189)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at
org.apache.jasper.servlet.JspServlet.service
(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch
(Dispatcher.java:194)
at
org.mortbay.jetty.servlet.Dispatcher.forward
(Dispatcher.java:129)
at
org.mortbay.jetty.servlet.Default.handleGet
(Default.java:239)
at
org.mortbay.jetty.servlet.Default.service
(Default.java:153)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:553)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1656)
at
org.mortbay.jetty.servlet.WebApplicationContext.ha
ndle(WebApplicationContext.java:549)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1606)
at org.mortbay.http.HttpServer.service
(HttpServer.java:862)
at org.jboss.jetty.Jetty.service
(Jetty.java:497)
at
org.mortbay.http.HttpConnection.service
(HttpConnection.java:752)
at
org.mortbay.http.HttpConnection.handleNext
(HttpConnection.java:916)
at
org.mortbay.http.HttpConnection.handle
(HttpConnection.java:769)
at
org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:202)
at org.mortbay.util.ThreadedServer.handle
(ThreadedServer.java:289)
at
org.mortbay.util.ThreadPool$PoolThread.run
(ThreadPool.java:455)
--
>Comment By: Muruga Chinnananchi (muruga)
Date: 2003-02-19 23:25
Message:
Logged In: YES
user_id=81331
If you want you can just copy the attached
MyClass.class to your c:/classes directory.
--
Comment By: Muruga Chinnananchi (muruga)
Date: 2003-02-19 23:12
Message:
Logged In: YES
user_id=81331
Here is the attachment.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-689653 ] Dynamic Class Loading issue
Bugs item #689653, was opened at 2003-02-19 23:10
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Muruga Chinnananchi (muruga)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic Class Loading issue
Initial Comment:
Problem Description:
Dynamically generated classes (while running jboss
server) that are placed under C:/classes/ directory
is not visible to the war file which is deployed
under server/default/deploy/ directory.
My Configuration:
--
Version: 3.2 RC 2.0 (with bundled Jetty)
Platform: Windows 2000
Jdk: 1.3.1_02
Steps to reproduce:
---
1. Create a classes directory under c:/
2. Add the classes directory to the conf/jboss-
service.xml
3. Start the jboss server in default mode ( run.bat)
4. Put the attached myapp.war file in the
default/deploy directory
5. Copy and Paste the following content in
MyClass.java and compile it and put it under
c:/classes directory.
package com.mycom;
public class MyClass
{
private String data;
public MyClass()
{
data = "f";
}
public String getData( )
{
return data;
}
}
6. Try invoking the MyApp war like below
http://localhost:8080/myapp/
7. You will see ClassDefNotFound printStackTrace
on the dos shell.
2003-02-19 14:32:46,078 WARN
[org.jboss.jbossweb] WARNING: Exception
for /myapp/
java.lang.NoClassDefFoundError:
com/mycom/MyClass
at java.lang.Class.newInstance0(Native
Method)
at java.lang.Class.newInstance
(Class.java:237)
at
org.apache.jasper.servlet.JspServletWrapper.getServl
et(JspServletWrapper.java:146)
at
org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:189)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at
org.apache.jasper.servlet.JspServlet.service
(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch
(Dispatcher.java:194)
at
org.mortbay.jetty.servlet.Dispatcher.forward
(Dispatcher.java:129)
at
org.mortbay.jetty.servlet.Default.handleGet
(Default.java:239)
at
org.mortbay.jetty.servlet.Default.service
(Default.java:153)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:553)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1656)
at
org.mortbay.jetty.servlet.WebApplicationContext.ha
ndle(WebApplicationContext.java:549)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1606)
at org.mortbay.http.HttpServer.service
(HttpServer.java:862)
at org.jboss.jetty.Jetty.service
(Jetty.java:497)
at
org.mortbay.http.HttpConnection.service
(HttpConnection.java:752)
at
org.mortbay.http.HttpConnection.handleNext
(HttpConnection.java:916)
at
org.mortbay.http.HttpConnection.handle
(HttpConnection.java:769)
at
org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:202)
at org.mortbay.util.ThreadedServer.handle
(ThreadedServer.java:289)
at
org.mortbay.util.ThreadPool$PoolThread.run
(ThreadPool.java:455)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-689653 ] Dynamic Class Loading issue
Bugs item #689653, was opened at 2003-02-19 23:10
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
Category: JBossMX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Muruga Chinnananchi (muruga)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic Class Loading issue
Initial Comment:
Problem Description:
Dynamically generated classes (while running jboss
server) that are placed under C:/classes/ directory
is not visible to the war file which is deployed
under server/default/deploy/ directory.
My Configuration:
--
Version: 3.2 RC 2.0 (with bundled Jetty)
Platform: Windows 2000
Jdk: 1.3.1_02
Steps to reproduce:
---
1. Create a classes directory under c:/
2. Add the classes directory to the conf/jboss-
service.xml
3. Start the jboss server in default mode ( run.bat)
4. Put the attached myapp.war file in the
default/deploy directory
5. Copy and Paste the following content in
MyClass.java and compile it and put it under
c:/classes directory.
package com.mycom;
public class MyClass
{
private String data;
public MyClass()
{
data = "f";
}
public String getData( )
{
return data;
}
}
6. Try invoking the MyApp war like below
http://localhost:8080/myapp/
7. You will see ClassDefNotFound printStackTrace
on the dos shell.
2003-02-19 14:32:46,078 WARN
[org.jboss.jbossweb] WARNING: Exception
for /myapp/
java.lang.NoClassDefFoundError:
com/mycom/MyClass
at java.lang.Class.newInstance0(Native
Method)
at java.lang.Class.newInstance
(Class.java:237)
at
org.apache.jasper.servlet.JspServletWrapper.getServl
et(JspServletWrapper.java:146)
at
org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:189)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at
org.apache.jasper.servlet.JspServlet.service
(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.Dispatcher.dispatch
(Dispatcher.java:194)
at
org.mortbay.jetty.servlet.Dispatcher.forward
(Dispatcher.java:129)
at
org.mortbay.jetty.servlet.Default.handleGet
(Default.java:239)
at
org.mortbay.jetty.servlet.Default.service
(Default.java:153)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dis
patch(WebApplicationHandler.java:280)
at
org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:553)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1656)
at
org.mortbay.jetty.servlet.WebApplicationContext.ha
ndle(WebApplicationContext.java:549)
at org.mortbay.http.HttpContext.handle
(HttpContext.java:1606)
at org.mortbay.http.HttpServer.service
(HttpServer.java:862)
at org.jboss.jetty.Jetty.service
(Jetty.java:497)
at
org.mortbay.http.HttpConnection.service
(HttpConnection.java:752)
at
org.mortbay.http.HttpConnection.handleNext
(HttpConnection.java:916)
at
org.mortbay.http.HttpConnection.handle
(HttpConnection.java:769)
at
org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:202)
at org.mortbay.util.ThreadedServer.handle
(ThreadedServer.java:289)
at
org.mortbay.util.ThreadPool$PoolThread.run
(ThreadPool.java:455)
--
>Comment By: Muruga Chinnananchi (muruga)
Date: 2003-02-19 23:12
Message:
Logged In: YES
user_id=81331
Here is the attachment.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689653&group_id=22866
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-686739 ] RMIAdaptorImpl NoClassDefFoundError
Bugs item #686739, was opened at 2003-02-14 12:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=686739&group_id=22866 Category: Build System Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Bernie Wing (wingba) Assigned to: Jason Dillon (user57) Summary: RMIAdaptorImpl NoClassDefFoundError Initial Comment: I have installed jboss-3.0.6_tomcat-4.1.18 on a Sun Sparc 5.8 UNIX system. After I unzipped the install file, I set JAVA_HOME (tried both J2SE 1.3.1 & 1.4.1) and JBOSS_HOME and then I did a run.sh to start the default server. I received this error message: 12:40:44,370 ERROR [MainDeployer] could not start deployment: file:/endeca/jboss-3.0.6_tomcat- 4.1.18/server/default/deploy/jmx-rmi-adaptor.sar/ java.lang.NoClassDefFoundError: org/jboss/jmx/adaptor/rmi/RMIAdaptorImpl at org.jboss.jmx.adaptor.rmi.RMIAdaptorService.startServic e(RMIAdaptorService.java:117 ) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:165) .. I found another RMIAdapter.class file in the jbossall- client.jar and used that one and everything started correctly. The size/date of the one that doesn't seem to work is: 2861 bytes dated Jan 26 01:59 The one that works is: 2863 bytes dated Jan 26 00:37 I submitted this in JBoss's Forum and they requested I post this a bug. -- >Comment By: Bernie Wing (wingba) Date: 2003-02-19 15:27 Message: Logged In: YES user_id=712580 I downloaded the jboss-3.0.6-src.tgz file and recompiled the RMIAdaptor classes with jdk 1.4.1 on my Solaris box. The size of the new RMIAdapter.class was 2863 bytes. The new re-compiled class worked fine. I do not see the above problem when I loaded JBoss on my Windows 2000 Pro machine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=686739&group_id=22866 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss Remoting Commit
My comments inline with JGH. I haven't really done much documentation on this yet, which is what I wanted to do in the next few days or so. I just wanted to get the initial codebase committed so we can have the benefit of others looking at it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Wednesday, February 19, 2003 3:41 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss Remoting Commit Woo hoo!! Thanks! This looks great!!! Will you guys mind if I fix minor oversights I notice (such as making handler names consistently upper case in ServerInvoker)? Partly so I don't forget and partly to think out loud as I read the code, here are my initial comments: 1. There's kind of an impedance mismatch between the remoting invoke method and all the interceptor invoke methods. The interceptors all have some kind of invocation object that includes method name, args, sig, and extra params: these are separate arguments in the remoting's invoke method. I think the same signature everywhere would make integration everywhere easier. In particular, I'd like the Invoker to implement whatever Interceptor interface we finally come up with. I'm mildly in favor of a single Invocation argument, even though it is not the most natural for the original jmx remoting use case. JGH: I think this is fine, and we just did an initial commit w/o fully knowing the other invokes. There are a handful of things that the remote invocation needs to have, such as the classbytes. But, one object (or at least a base object that the remoting can extend) would be much cleaner for all. 2. I need to have essentially client and server side invoker interceptors (e.g. the InvokerXAResource). I'm sure others will think of uses for this when it is available. If we decide one way or another on (1) I can implement this possibly using an adapter that could be removed if we decide to go with a single Invocation argument. JGH: That's fine if I understand what you're saying. 3. So far I've just looked at the socket server invoker. I want to be able to plug in a thread pool (implementing a standard interface). I also want the stuff that's done in the thread to be set up as an interceptor chain. For instance, I want the "extract the xid from the invocation and import it or prepare/commit/rollback/recover/forget" to be in one or more interceptors. I think most of this is taken care of by the selection of ServerInvocationHandler: I can make these be my interceptors. I wonder if a clearer architecture would move the ServerInvoker invoke(byte[]) method into a separate class that the transport mechanism runnable classes subclass. This object would then be the standardized object submitted to something like the jca 1.5 work interface. [this is the jca 1.5 thread pool, and it provides for both synchronous and asynchronous execution of a Work object. I like the idea of always using the same kind of object, but the Work interface itself is not appropriate since the contents of the ExecutionContext (tx context or xid) would not be determined until the thread starts processing. I'd like to build the jca 1.5 implementation out of more basic units.] JGH: There is a ThreadPool using the concurrent package in the SocketClientPool I believe. Are you doing this for client side async invocations? The reason both client and server invokers extend from abstract is to get the basic classloading/marshalling/unmarshalling logic since both sides have similar logic. 4. I haven't found yet how the client invokers get set up in the client. Are there situations in which they are obtained through rmi? Should they be mbeans in a client-side jmx server? Should this be optional? Working on the TrunkInvoker I made the client side piece into several mbeans that got created/registered when the first one got deserialized as a remote object. This considerably simplified keeping track of the pieces. Is something like this a good idea here too or at least compatible with what you have? JGH: So, an implementaiton of a ServerInvoker represents a physical wire transport - such as Socket, IIOP, SOAP, RMI, etc. An ServerInvocationHandler represents a invocation context subsystem handlers, such as JMX, JMS, etc. The relationship is 1..* ServerInvoker-ServerInvocationHandler. When the client invoker builds the invocation, he will tell the invocation which subsystem he is invoking against - since the client side Invoker will represent a subsystem context from the callers context (i.e., in JMX it's a dynamic proxy that looks like a MBeanServer). Currently, the way I'm setting it up is via JMX attribute in XML. There's an example in the javadoc of ConnectorMBean (I think). I'll try and check in a service.xml file as an example in the next day or so. So, my thought is that the connectors (ServerInvoker implementations) would be registered in the jboss-service.xml *before* any of the subsystems along wi
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 19-February-2003
JBoss daily test results SUMMARY Number of tests run: 1042 Successful tests: 1040 Errors:1 Failures: 1 [time of test: 2003-02-19.12-05 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.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-02-19.12-05 for details of this test. 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Remoting Commit
Woo hoo!! Thanks! This looks great!!! Will you guys mind if I fix minor oversights I notice (such as making handler names consistently upper case in ServerInvoker)? Partly so I don't forget and partly to think out loud as I read the code, here are my initial comments: 1. There's kind of an impedance mismatch between the remoting invoke method and all the interceptor invoke methods. The interceptors all have some kind of invocation object that includes method name, args, sig, and extra params: these are separate arguments in the remoting's invoke method. I think the same signature everywhere would make integration everywhere easier. In particular, I'd like the Invoker to implement whatever Interceptor interface we finally come up with. I'm mildly in favor of a single Invocation argument, even though it is not the most natural for the original jmx remoting use case. 2. I need to have essentially client and server side invoker interceptors (e.g. the InvokerXAResource). I'm sure others will think of uses for this when it is available. If we decide one way or another on (1) I can implement this possibly using an adapter that could be removed if we decide to go with a single Invocation argument. 3. So far I've just looked at the socket server invoker. I want to be able to plug in a thread pool (implementing a standard interface). I also want the stuff that's done in the thread to be set up as an interceptor chain. For instance, I want the "extract the xid from the invocation and import it or prepare/commit/rollback/recover/forget" to be in one or more interceptors. I think most of this is taken care of by the selection of ServerInvocationHandler: I can make these be my interceptors. I wonder if a clearer architecture would move the ServerInvoker invoke(byte[]) method into a separate class that the transport mechanism runnable classes subclass. This object would then be the standardized object submitted to something like the jca 1.5 work interface. [this is the jca 1.5 thread pool, and it provides for both synchronous and asynchronous execution of a Work object. I like the idea of always using the same kind of object, but the Work interface itself is not appropriate since the contents of the ExecutionContext (tx context or xid) would not be determined until the thread starts processing. I'd like to build the jca 1.5 implementation out of more basic units.] 4. I haven't found yet how the client invokers get set up in the client. Are there situations in which they are obtained through rmi? Should they be mbeans in a client-side jmx server? Should this be optional? Working on the TrunkInvoker I made the client side piece into several mbeans that got created/registered when the first one got deserialized as a remote object. This considerably simplified keeping track of the pieces. Is something like this a good idea here too or at least compatible with what you have? 5. Since I think it is possible that jmx could be used without aop and aop without jmx, I'd like to suggest that we make a new module "invocation" that has the interceptor interface, and the Invocation and InvocationResponse objects in it. Otherwise I don't see how to unify our view of these fundamental classes without intruducing artificial dependencies. I'd like to get to work on the interceptor stuff I mentioned, so I'd like to get comments on this soon so at least I'll know how much I'll have to fight:- This is awesome work. Thanks again david jencks On 2003.02.19 00:54 Jeff Haynie wrote: > I commited the jboss-remoting code tonight. There is now a separate > module named jboss-remoting, and it is aliased in jboss-mx and > jboss-head (because mx needs it). > > It looks like all 3 modules are compiling fine. There is more work that > Tom and I are doing this week to try and wrap up the initial testing - > however, the code should compile fine and the code isn't yet referenced > at all anywhere in the server so shouldn't cause any problems. If it > does cause problems in the next day or so, please let me or Tom Elrod > ([EMAIL PROTECTED]) if you have any issues - or just fix them > and let me and him know. > > -Jeff > > http://www.freeroller.net/page/jhaynie > > > > > > > Message > > > > I commited > the > jboss-remoting code tonight. There is now a separate module named > jboss-remoting, and it is aliased in jboss-mx and jboss-head (because mx > needs > it). > > It looks like > all 3 > modules are compiling fine. There is more work that Tom and I are > doing > this week to try and wrap up the initial testing - however, the code > should > compile fine and the code isn't yet referenced at all anywhere in the > server so > shouldn't cause any problems. If it does cause problems in the next > day or > so, please let me or Tom Elrod ( href="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]) if > you > have any issues - or just fix them and let me and him know. > > > class=32332330
[JBoss-dev] [ jboss-Bugs-689562 ] Hotdeploy of ear w/ war fails under 3.0.6, not under 3.0.4
Bugs item #689562, was opened at 2003-02-19 20:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=689562&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: James Higginbotham (jwhigginbotham) Assigned to: Nobody/Anonymous (nobody) Summary: Hotdeploy of ear w/ war fails under 3.0.6, not under 3.0.4 Initial Comment: OS: Windows XP JDK: 1.4.1_01 (see attached boot.log, ucl.log, server.log) I have an ear with the following structure: $ jar -tvf controlpanel.ear 0 Wed Feb 19 14:01:10 CST 2003 META-INF/ 55 Wed Feb 19 14:01:10 CST 2003 META- INF/MANIFEST.MF 91982 Wed Feb 19 14:01:10 CST 2003 controlpanel.war 0 Wed Feb 19 14:01:10 CST 2003 lib/ 18079 Wed Feb 19 13:20:24 CST 2003 lib/calvary- controlpanel.jar 9807 Wed Feb 19 13:20:20 CST 2003 lib/calvary- cms.jar 118453 Wed Feb 12 16:08:14 CST 2003 lib/commons- beanutils.jar 297992 Wed Feb 12 16:08:20 CST 2003 lib/commons- collections.jar 81927 Wed Feb 12 16:08:22 CST 2003 lib/commons- dbcp.jar 100160 Wed Feb 12 16:08:24 CST 2003 lib/commons- digester.jar 14248 Wed Feb 12 16:08:24 CST 2003 lib/commons- fileupload-1.0-dev.jar 90424 Wed Feb 12 16:08:28 CST 2003 lib/commons- io.jar 196279 Wed Feb 12 16:08:30 CST 2003 lib/commons- lang-1.1-dev.jar 28618 Wed Feb 12 16:08:30 CST 2003 lib/commons- logging.jar 37499 Wed Feb 12 16:08:32 CST 2003 lib/commons- pool.jar 35675 Wed Feb 12 16:08:32 CST 2003 lib/commons- resources.jar 44391 Wed Feb 12 16:08:34 CST 2003 lib/commons- validator.jar 65368 Wed Feb 12 16:08:36 CST 2003 lib/jakarta-oro.jar 350677 Wed Feb 12 16:16:44 CST 2003 lib/log4j- 1.2.7.jar 1728861 Wed Feb 12 16:07:56 CST 2003 lib/xercesImpl.jar 108484 Wed Feb 12 16:07:58 CST 2003 lib/xml-apis.jar 6727 Wed Feb 12 16:16:16 CST 2003 lib/jdbc2_0- stdext.jar 488695 Wed Feb 12 16:16:28 CST 2003 lib/struts.jar 29922 Wed Feb 12 16:14:08 CST 2003 lib/slide-taglib- common.jar 16939 Wed Feb 12 16:14:08 CST 2003 lib/slide-taglib- struts.jar 479 Wed Feb 12 16:06:56 CST 2003 META- INF/application.xml it has the following application.xml: http://java.sun.com/j2ee/dtds/application_1_2.d td"> Calvary Austin Control Panel The content management system control panel controlpanel.war /controlpanel the contained war has the following structure: $ jar -tvf controlpanel.war 0 Wed Feb 19 14:01:10 CST 2003 META-INF/ 1191 Wed Feb 19 14:01:10 CST 2003 META- INF/MANIFEST.MF 0 Wed Feb 19 12:30:06 CST 2003 browser/ 0 Wed Feb 12 17:17:58 CST 2003 images/ 0 Wed Feb 19 12:32:04 CST 2003 layouts/ 0 Wed Feb 12 17:17:58 CST 2003 locks/ 0 Wed Feb 12 17:17:58 CST 2003 Templates/ 0 Wed Feb 12 17:17:58 CST 2003 WEB-INF/ 0 Wed Feb 12 17:17:58 CST 2003 WEB-INF/classes/ 4346 Wed Feb 12 16:06:56 CST 2003 addUser.jsp 45 Wed Feb 19 12:30:06 CST 2003 browser/browser_tile.jsp 3964 Wed Feb 12 16:06:56 CST 2003 editUser.jsp 526 Wed Feb 12 16:06:56 CST 2003 images/background.jpg 1081 Wed Feb 12 16:06:56 CST 2003 images/dot.jpg 622 Wed Feb 12 16:06:56 CST 2003 images/logo blank.jpg 15882 Wed Feb 12 16:06:58 CST 2003 images/logo.jpg 1283 Wed Feb 12 16:06:58 CST 2003 images/subhead blank.jpg 3235 Wed Feb 12 16:06:58 CST 2003 images/subhead1.jpg 3378 Wed Feb 12 16:06:58 CST 2003 images/subhead2.jpg 176 Wed Feb 12 16:06:56 CST 2003 index.jsp 416 Wed Feb 12 16:06:56 CST 2003 index_tile.jsp 6711 Wed Feb 19 14:00:56 CST 2003 layouts/masterlayout.jsp 4014 Wed Feb 12 16:06:58 CST 2003 locks/locks_tile.jsp 4267 Wed Feb 12 16:06:56 CST 2003 locks.jsp 2349 Wed Feb 12 16:06:56 CST 2003 orig-index.jsp 4488 Wed Feb 12 16:06:56 CST 2003 style.css 6602 Wed Feb 12 16:06:56 CST 2003 template.html 6212 Wed Feb 12 16:06:58 CST 2003 Templates/standard-page.dwt 4401 Wed Feb 12 16:06:56 CST 2003 users.jsp 1973 Wed Feb 12 16:07:00 CST 2003 WEB- INF/classes/controlpanel-resources.properties 12443 Wed Feb 12 16:07:00 CST 2003 WEB- INF/classes/Domain.xml 7489 Wed Feb 12 16:06:58 CST 2003 WEB-INF/slide- struts.tld 8486 Wed Feb 12 16:06:58 CST 2003 WEB-INF/struts- bean.tld 4832 Wed Feb 19 12:22:58 CST 2003 WEB-INF/struts- config.xml 18346 Wed Feb 12 16:06:58 CST 2003 WEB-INF/struts- config_1_0.dtd 33776 Wed Feb 12 16:06:58 CST 2003 WEB-INF/struts- config_1_1.dtd 63186 Wed Feb 12 16:06:58 CST 2003 WEB-INF/struts- html.tld 13869 Wed Feb 12 16:06:58 CST 2003 WEB-INF/struts- logic.tld 61672 Wed Feb 12 16:06:58 CST 2003 WEB-INF/struts- nested.tld 1558 Wed Feb 12 16:06:58 CST 2003 WEB-INF/struts- template.tld 7518 Wed Feb 12 16:06:58 CST 2003 WEB-INF/struts- tiles.tld 1598 Wed Feb 12 16:06:58 CST 2003 WEB-INF/tiles- config.dtd 12119 Wed Feb 12 16:06:58 CST 2003 WEB-INF/tiles- config_1_1.dtd 977 Wed Feb 19 12:22:02 CST 2003 WEB-INF/tiles- defs.xml 1511 Wed Feb 12 16:06:58 CST 2003 WEB- INF/validation.xml 9829 Wed Feb 12 16:06:58 CST 2003 WEB-
RE: [JBoss-dev] Dependant classloader repository
simplify :)
marcf
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On
> Behalf Of Peter Antman
> Sent: Wednesday, February 19, 2003 12:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Dependant classloader repository
>
>
> ons 2003-02-19 klockan 15.09 skrev David Jencks:
> > On 2003.02.19 03:43 Peter Antman wrote:
> > > On Tue, 2003-02-18 at 20:08, David Jencks wrote:
> > > > I don't yet understand what problem you are trying to
> solve. The
> > > problem I
> > > > know of with the current deployment set up and
> LoaderRepositories
> > > > is
> > > that
> > > > the only package type you can specify a
> LoaderRepsository in is an
> > > .ear.
> > > > This however is easy to fix without more kinds of
> > > > LoaderRepositories.
> > > You
> > > > can already add several .ears to the same named
> LoaderRespository
> > > > and
> > > (if
> > > > there are no bugs) redeploy each independently.
> > >
> > > Could have been working but is not:
> > >
> > > if(
> > >
> di.repositoryName.equals(DeploymentInfo.DEFAULT_LOADER_REPOSITORY)
> > > == false )
> > > {
> > > log.debug("Destroying ear loader
> > > repository:"+di.repositoryName);
> > > try
> > > {
> > > this.server.unregisterMBean(di.repositoryName);
> > > }
> > > catch(Exception e)
> > > {
> > > log.warn("Failed to unregister ear loader
> repository", e);
> > > }
> > > }
> > >
> > > The first ear to get redeployed will destroy the repository! And
> > > will make the other ear:s *very* confused.
> >
> > OK, but thats a bug in the implementation. Where is this code?
> >
>
> I really do not know if it should be considered a bug;
> someone must have the responibility to remove it when its not
> used; and that can only be done by tracking dependandices.
> (Its in EARDeployer)
>
> > >
> > > My experience is also that a component that gets its classloader
> > > swaped under the hood without beeing properly redeployed
> will behave
> > > very eratic. Thats why.
>
> Bu my experimental code solves that by having a depenant
> tracking proxy wich holds the deployment info object for its
> component and is therefor capable of redeploying it.
>
> What would be best I guess is to just see to it that the
> classes involved is really possible to sublclass in
> ameaningfull way; so that it is possible to create your on
> repository/tracking mechanisms.
>
> //Peter
>
> //Peter
> >
> > You can't do that with standard mbeans, the classs--mbean
> dependency
> > is tracked and used to undeploy/redeploy the mbean instance as the
> > classloader is cycled. Maybe we can extend this to modelmbeans and
> > ejbs.
> >
> > thanks
> > david
> >
> > >
> > > //Peter
> > >
> > > > I don't know if all
> > > > dependencies between .ears are properly taken care of.
> > > >
> > > > What will having a deeper hierarchy of
> LoaderRepositories get you?
> > > > I
> > > don't
> > > > understand the situation in which this would be useful.
> > > >
> > > > Also, I am planning on moving the dependency
> computatations out of
> > > > ServiceController and into an mbean interceptor (with
> some global
> > > > supporting objects).
> > > >
> > > > thanks
> > > > david jencks
> > > >
> > > >
> > > >
> > > > On 2003.02.18 13:51 Peter Antman wrote:
> > > > >
> > > > >
> > > > > Hi,
> > > > > I would like to share some ideas about extensions to
> the current
> > > > > classloader to see if I am totally on the wrong track
> and if it
> > > > > perhaps would be a welcome addition to JBoss.
> > > > >
> > > > > First I have to say that I still find the "new" classloader
> > > > > architecture somewhat limiting. If you have the following two
> > > > > conditions:
> > > > >
> > > > > 1. You do not want components/classes globally
> available in the
> > > > >repository because this stops from implementation/interface
> > > > >versioning.
> > > > > 2. You want to be able to partition your stuff in
> several deployable
> > > > >components (locally/remote), but which uses each
> other (EJB:s
> > > > >calling EJB:s, MBeans calling MBeans (locally and
> through RMI),
> > > > >MBeans calling EJB:s and EJB:s calling MBeans).
> > > > >
> > > > > The you basically have to do a couple of things:
> > > > >
> > > > > 1. Be very paranoid about what classes get stuffed into your
> > > > >components.
> > > > > 2. Up to the last classloader change stuff almost
> every class at
> > > > > the global
> > > > >level anyhow, through lib or a dynamic classloader
> deployer,
> > > > > and after
> > > > >the latest changes at least place all interfaces statically
> > > > >available in the global classloader repository.
> > > > >
> > > > > To me this hinders one of the aspects that has always
> was dear
> > > > > to
> > > > > me: hot redeploy.
> > > > >
> > > > > Here is an id
Re: [JBoss-dev] Dependant classloader repository
ons 2003-02-19 klockan 15.09 skrev David Jencks:
> On 2003.02.19 03:43 Peter Antman wrote:
> > On Tue, 2003-02-18 at 20:08, David Jencks wrote:
> > > I don't yet understand what problem you are trying to solve. The
> > problem I
> > > know of with the current deployment set up and LoaderRepositories is
> > that
> > > the only package type you can specify a LoaderRepsository in is an
> > .ear.
> > > This however is easy to fix without more kinds of LoaderRepositories.
> > You
> > > can already add several .ears to the same named LoaderRespository and
> > (if
> > > there are no bugs) redeploy each independently.
> >
> > Could have been working but is not:
> >
> > if(
> > di.repositoryName.equals(DeploymentInfo.DEFAULT_LOADER_REPOSITORY) ==
> > false )
> > {
> > log.debug("Destroying ear loader
> > repository:"+di.repositoryName);
> > try
> > {
> > this.server.unregisterMBean(di.repositoryName);
> > }
> > catch(Exception e)
> > {
> > log.warn("Failed to unregister ear loader repository", e);
> > }
> > }
> >
> > The first ear to get redeployed will destroy the repository! And will
> > make the other ear:s *very* confused.
>
> OK, but thats a bug in the implementation. Where is this code?
>
I really do not know if it should be considered a bug; someone must have
the responibility to remove it when its not used; and that can only be
done by tracking dependandices. (Its in EARDeployer)
> >
> > My experience is also that a component that gets its classloader swaped
> > under the hood without beeing properly redeployed will behave very
> > eratic. Thats why.
Bu my experimental code solves that by having a depenant tracking proxy
wich holds the deployment info object for its component and is therefor
capable of redeploying it.
What would be best I guess is to just see to it that the classes
involved is really possible to sublclass in ameaningfull way; so that it
is possible to create your on repository/tracking mechanisms.
//Peter
//Peter
>
> You can't do that with standard mbeans, the classs--mbean dependency is
> tracked and used to undeploy/redeploy the mbean instance as the classloader
> is cycled. Maybe we can extend this to modelmbeans and ejbs.
>
> thanks
> david
>
> >
> > //Peter
> >
> > > I don't know if all
> > > dependencies between .ears are properly taken care of.
> > >
> > > What will having a deeper hierarchy of LoaderRepositories get you? I
> > don't
> > > understand the situation in which this would be useful.
> > >
> > > Also, I am planning on moving the dependency computatations out of
> > > ServiceController and into an mbean interceptor (with some global
> > > supporting objects).
> > >
> > > thanks
> > > david jencks
> > >
> > >
> > >
> > > On 2003.02.18 13:51 Peter Antman wrote:
> > > >
> > > >
> > > > Hi,
> > > > I would like to share some ideas about extensions to the current
> > > > classloader to see if I am totally on the wrong track and if it
> > > > perhaps would be a welcome addition to JBoss.
> > > >
> > > > First I have to say that I still find the "new" classloader
> > > > architecture somewhat limiting. If you have the following two
> > > > conditions:
> > > >
> > > > 1. You do not want components/classes globally available in the
> > > >repository because this stops from implementation/interface
> > > >versioning.
> > > > 2. You want to be able to partition your stuff in several deployable
> > > >components (locally/remote), but which uses each other (EJB:s
> > > >calling EJB:s, MBeans calling MBeans (locally and through RMI),
> > > >MBeans calling EJB:s and EJB:s calling MBeans).
> > > >
> > > > The you basically have to do a couple of things:
> > > >
> > > > 1. Be very paranoid about what classes get stuffed into your
> > > >components.
> > > > 2. Up to the last classloader change stuff almost every class at the
> > > > global
> > > >level anyhow, through lib or a dynamic classloader deployer, and
> > > > after
> > > >the latest changes at least place all interfaces statically
> > > >available in the global classloader repository.
> > > >
> > > > To me this hinders one of the aspects that has always was dear to
> > > > me: hot redeploy.
> > > >
> > > > Here is an idea (with a working test implementation) to make these
> > > > obstacles possible to overcome:
> > > >
> > > > Create a repository which may delegate to other repositories (not
> > just
> > > > a parent repository) and make this configurable in jboss-app.xml
> > > >
> > > > Create dependency checks so that lifecykling a component with a
> > > > repository which have dependent repositories will make also these
> > > > components "lifecyking".
> > > >
> > > > Here is the basic steps I took to create this:
> > > >
> > > > 1. Create a DelegatingLoaderRepository which extends
> > > >HeirarchicalLoaderRepository3. The delegating reposito
RE: [JBoss-dev] TxInterceptor split is really really good
On 2003.02.19 09:37 Bill Burke wrote: > > > > What you implemented is fine. My only problem with it is that I > > think it is more logical to let the server decide if it needs the > > tx, and that I think the registration callback could be avoided > > (with minimal redundant client side bookkeeping) even if the > > decision is made on the server side. > > > > I got the impression that this implementation would also be used > > in the other invokers, and that made me worry about CORBA > > interoperability. If this approach will not be used with the IIOP > > invoker, I have no problem with it. > > > > Yes this was my exact worry and still is. That we'll have to have a > different set of interceptors on the server side for different > transports. > This is unexceptable because we want each EJB to be able to listen to and > service calls from different transports at the same time. > > David, I'm not suggesting to redesign your code, but is the design > flexible > enough so that we could switch to a server-side based design? Iteration > is > a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says "if there is a transaction in the context it must always be transmitted and imported on the server" whereas j2ee does not always need to import the tx. The purpose of the client side interceptor is to not generate tx branches that won't be used. I think that any reasonable corba implementation is going to follow corba semantics and always generate a transaction branch on the client for the remote call, since as far as the corba spec goes, if the call is made within a tx the transaction will in fact be used on the server. In my view the heaviest part of the process is generating a tx branch on the client: once it is generated, then it has to be prepared and/or committed. The communication overhead on these messages is likely to dwarf any other resource usage. The choices I can see here are: 1. only generate the branch if it is needed, but do it right away. This is what I implemented and I think it is simplest and the only one that is likely to be comprehensible when someone looks at it in a week or two. 2. Only generate the branch if it is needed but do it after the work is done. I think this is Ole's proposal. This introduces a lot of bookkeeping on the client to associate client side transactions to branches. I don't think I'd be able to maintain this code, in a week I wouldn't remember how it worked. After spending a day to figure it out, I'd simplify it to (1). 3. Always generate a branch immediately, but have the xaresource return read-only on prepare if the tx did not need to be imported. This is unacceptable because it forces 2pc in the case that there is only one other branch. Don't we need a client side method-to-method-attributes map anyway for many other purposes such as determining if a return value can be cached? david > > Bill > > > > --- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Feature Requests-689313 ] Min-max connection change fails on hot system
Feature Requests item #689313, was opened at 2003-02-19 15:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376688&aid=689313&group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Barney Rubble (verilet) Assigned to: Nobody/Anonymous (nobody) Summary: Min-max connection change fails on hot system Initial Comment: Changed the min-max settings in oracle-service.xml from 0-0 to 17-17 and database access failed: stack traces. Using the JMX console to stop, change and restart works fine. Using the JMX console without a stoppage fails. However, once you successfully make that change you can apply additional changes without stoppign and restarting the service. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376688&aid=689313&group_id=22866 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really good
> > What you implemented is fine. My only problem with it is that I > think it is more logical to let the server decide if it needs the > tx, and that I think the registration callback could be avoided > (with minimal redundant client side bookkeeping) even if the > decision is made on the server side. > > I got the impression that this implementation would also be used > in the other invokers, and that made me worry about CORBA > interoperability. If this approach will not be used with the IIOP > invoker, I have no problem with it. > Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is really really good
David Jencks wrote: > I'm now quite confused about what you are arguing for. Basically I am arguing that it seems more logical to let the server decide if the server needs the transaction, instead of offloading this decision to the client. That approach involves some (cheap) local bookkeeping in the client and the transmission of an unneeded tx id. But it is still possible for the server to avoid the expensive import of that tx id. However, I have no strong feelings against your approach - as long as it is not done for the IIOP transport. But I was worrying if you were about to do the same thing for the IIOP transport - which could break interoperability with non-Java CORBA clients. > 1. There is currently no support whatsoever in any jboss version for > transactions over CORBA/IIOP, nor has there ever been. I have not yet > considered how best to implement this. I don't think this will be used > very much so I am willing to provide a special implementation for this if > it will not fit into the jta framework well. Support for full JTA/OTS interoperability is possible because the tx id in JBoss is basically untyped (java.lang.Object). When a transaction comes in, the TransactionPropagationContextImporter implementation will see a org.omg.CosTransactions.PropagationContext if the call comes in via IIOP, and if the call comes via JRMP it will have whatever type you decide to use (currently GlobalId, but that does not hold the tx branch id). The JTA TM can use this type to find out how to communicate with the originating TM. For outgoing calls, the TransactionPropagationContextFactory interface is used. This may have to change, so that a specific type of wire tx id is requested by the outgoing transport code. When an OTS id is requested, an org.omg.CosTransactions.PropagationContext instance is returned after the TM has set up the needed OTS callback server. This way, we can support both IIOP and JRMP with transactions, without worrying if IIOP clients and servers are Java-based, or implemented in other languages. I currently don't need this, but I think we should keep in mind that someone might need it some day. > 2. I can't tell from the specs I have read so far what the relationship > between the CORBA tx policy and the j2ee tx policy is supposed to be. It looks to me like JacORB is still at OTS 1.1 (ie. pre-OTSPolicy), so this may not be relevant yet. But when JacORB gets up-to-date on this, we may want to use the OTS tx policies. The OTS policy only supports the equivalents of never, supports and mandatory. Since the policy is included in the address (IOR), the client knows if it needs to send a tx id along with the call. Unfortunately, the OTS policy can only be defined at the object level and not at the method level, I think. > 3. JTA performs the registration of the branch at the same time as the xid > is generated through the tx.enlist(XAResource) and xares.start(xid) calls. > There is no other way to get an xid. > > 4. Your final arguments look to me as if they are supporting exactly what I > implemented. Are you aware that the current implementation works only with > the trunk invoker? Are you aware that the InvokerXAResource is a > client-side mbean? What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Best Regards, Ole Husgaard. --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] build clean fails again
You may be getting that error if the jboss-jsr77.jar is on Ant's classpath at the time the delete task is run. Ant will not delete a jar it finds on the classpath. I've noticed this behaviour in other projects, not sure if it's the case here, but it's certainly worth a look. Dustin > I think its some buildmagic crap but I have not been able to > track it down. > Your stuck with a manual delete for now. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Igor Fedorenko" <[EMAIL PROTECTED]> > To: "jboss-development" <[EMAIL PROTECTED]> > Sent: Tuesday, February 18, 2003 11:56 AM > Subject: [JBoss-dev] build clean fails again > > > > Hi, > > > > I keep getting > > > > BUILD FAILED > > > jar:file:/S:/jboss/Branch_3_2/tools/lib/buildmagic-tasks.jar!/ org/jboss/tools/bu > > ildmagic/common.xml:124: Unable to delete file > > S:\jboss\Branch_3_2\management\ou > > tput\lib\jboss-jsr77.jar > > > > whenever I try to build clean under win2k/SP2, sun > jdk141_01. The file > > is not locked because I can delete it manually from the > same command > > window I executed the build in. It's all started I believe > yesterday > > after I did a clean checkout. Not a big deal, but kind of > annoying. Has > > anyone seen this recently? > > > > > > -- > > Igor Fedorenko > > Think smart. Think automated. Think Dynamics. > > www.thinkdynamics.com > > > > > > > > --- > > 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 > --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Dependant classloader repository
On 2003.02.19 03:43 Peter Antman wrote:
> On Tue, 2003-02-18 at 20:08, David Jencks wrote:
> > I don't yet understand what problem you are trying to solve. The
> problem I
> > know of with the current deployment set up and LoaderRepositories is
> that
> > the only package type you can specify a LoaderRepsository in is an
> .ear.
> > This however is easy to fix without more kinds of LoaderRepositories.
> You
> > can already add several .ears to the same named LoaderRespository and
> (if
> > there are no bugs) redeploy each independently.
>
> Could have been working but is not:
>
> if(
> di.repositoryName.equals(DeploymentInfo.DEFAULT_LOADER_REPOSITORY) ==
> false )
> {
> log.debug("Destroying ear loader
> repository:"+di.repositoryName);
> try
> {
> this.server.unregisterMBean(di.repositoryName);
> }
> catch(Exception e)
> {
> log.warn("Failed to unregister ear loader repository", e);
> }
> }
>
> The first ear to get redeployed will destroy the repository! And will
> make the other ear:s *very* confused.
OK, but thats a bug in the implementation. Where is this code?
>
> My experience is also that a component that gets its classloader swaped
> under the hood without beeing properly redeployed will behave very
> eratic. Thats why.
You can't do that with standard mbeans, the classs--mbean dependency is
tracked and used to undeploy/redeploy the mbean instance as the classloader
is cycled. Maybe we can extend this to modelmbeans and ejbs.
thanks
david
>
> //Peter
>
> > I don't know if all
> > dependencies between .ears are properly taken care of.
> >
> > What will having a deeper hierarchy of LoaderRepositories get you? I
> don't
> > understand the situation in which this would be useful.
> >
> > Also, I am planning on moving the dependency computatations out of
> > ServiceController and into an mbean interceptor (with some global
> > supporting objects).
> >
> > thanks
> > david jencks
> >
> >
> >
> > On 2003.02.18 13:51 Peter Antman wrote:
> > >
> > >
> > > Hi,
> > > I would like to share some ideas about extensions to the current
> > > classloader to see if I am totally on the wrong track and if it
> > > perhaps would be a welcome addition to JBoss.
> > >
> > > First I have to say that I still find the "new" classloader
> > > architecture somewhat limiting. If you have the following two
> > > conditions:
> > >
> > > 1. You do not want components/classes globally available in the
> > >repository because this stops from implementation/interface
> > >versioning.
> > > 2. You want to be able to partition your stuff in several deployable
> > >components (locally/remote), but which uses each other (EJB:s
> > >calling EJB:s, MBeans calling MBeans (locally and through RMI),
> > >MBeans calling EJB:s and EJB:s calling MBeans).
> > >
> > > The you basically have to do a couple of things:
> > >
> > > 1. Be very paranoid about what classes get stuffed into your
> > >components.
> > > 2. Up to the last classloader change stuff almost every class at the
> > > global
> > >level anyhow, through lib or a dynamic classloader deployer, and
> > > after
> > >the latest changes at least place all interfaces statically
> > >available in the global classloader repository.
> > >
> > > To me this hinders one of the aspects that has always was dear to
> > > me: hot redeploy.
> > >
> > > Here is an idea (with a working test implementation) to make these
> > > obstacles possible to overcome:
> > >
> > > Create a repository which may delegate to other repositories (not
> just
> > > a parent repository) and make this configurable in jboss-app.xml
> > >
> > > Create dependency checks so that lifecykling a component with a
> > > repository which have dependent repositories will make also these
> > > components "lifecyking".
> > >
> > > Here is the basic steps I took to create this:
> > >
> > > 1. Create a DelegatingLoaderRepository which extends
> > >HeirarchicalLoaderRepository3. The delegating repository takes a
> > >list of repositories to delegate to if the normal loading fails.
> > >
> > > 2. Factor out repository handling in EARDeployer, extends EARDeployer
> > >with a DependantEARDeployer.
> > >
> > >EAR:s deployed through this new deployer may set up dependencies
> > >between its own repository and the repositories of other
> > >components. These other repositories must however also have been
> > >created through the dependent deployer; because the repository
> must
> > >be installed in the ServiceController.
> > >
> > >For a repository created through the DependantEARDeployer a
> > >RepositoryProxy is created which will work as a proxy to track
> > >dependency events from the ServiceController. The proxy also takes
> > >the DeploymentInfo of the components; which makes it possible for
> > >the proxy to
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version "1.4.1_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01) Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE symbol : class NetworkRegistryMBean location: class org.jboss.mx.remoting.tracker.MBeanTracker server.getMBeanServer().isInstanceOf(mbean,NetworkRegistryMBean.class.getName())==false) ^ /home/jboss/jbossci/jboss-head/jmx/src/main/org/jboss/mx/remoting/tracker/MBeanTracker.java:449: cannot resolve symbol symbol : class NetworkNotification location: class org.jboss.mx.remoting.tracker.MBeanTracker else if (notification instanceof NetworkNotification) ^ /home/jboss/jbossci/jboss-head/jmx/src/main/org/jboss/mx/remoting/tracker/MBeanTracker.java:451: cannot resolve symbol symbol : class NetworkNotification location: class org.jboss.mx.remoting.tracker.MBeanTracker NetworkNotification nn=(NetworkNotification)notification; ^ /home/jboss/jbossci/jboss-head/jmx/src/main/org/jboss/mx/remoting/tracker/MBeanTracker.java:451: cannot resolve symbol symbol : class NetworkNotification location: class org.jboss.mx.remoting.tracker.MBeanTracker NetworkNotification nn=(NetworkNotification)notification; ^ /home/jboss/jbossci/jboss-head/jmx/src/main/org/jboss/mx/remoting/tracker/MBeanTracker.java:453: cannot resolve symbol symbol : variable NetworkNotification location: class org.jboss.mx.remoting.tracker.MBeanTracker if (type.equals(NetworkNotification.SERVER_ADDED)) ^ /home/jboss/jbossci/jboss-head/jmx/src/main/org/jboss/mx/remoting/tracker/MBeanTracker.java:456: cannot resolve symbol symbol : class Identity location: class org.jboss.mx.remoting.tracker.MBeanTracker Identity ident = nn.getIdentity(); ^ /home/jboss/jbossci/jboss-head/jmx/src/main/org/jboss/mx/remoting/tracker/MBeanTracker.java:460: cannot resolve symbol symbol : variable NetworkNotification location: class org.jboss.mx.remoting.tracker.MBeanTracker else if (type.equals(NetworkNotification.SERVER_REMOVED)) ^ /home/jboss/jbossci/jboss-head/jmx/src/main/org/jboss/mx/remoting/tracker/MBeanTracker.java:463: cannot resolve symbol symbol : class Identity location: class org.jboss.mx.remoting.tracker.MBeanTracker Identity ident = nn.getIdentity(); ^ /home/jboss/jbossci/jboss-head/jmx/src/main/org/jboss/mx/remoting/tracker/MBeanTracker.java:675: cannot resolve symbol symbol : class ConnectionFailedException location: class org.jboss.mx.remoting.tracker.MBeanTracker catch (ConnectionFailedException ce) ^ 82 errors BUILD FAILED file:/home/jboss/jbossci/jboss-head/jmx/../tools/etc/buildfragments/targets.ent:45: Compile failed; see the compiler error output for details. Total time: 32 seconds --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Dependant classloader repository
Here are the diff for you to look at, without beeing ment as the final
versions:
First for mx loading:
Common subdirectories:
/home/pra/src/rw/jboss-versions/3.0.x/ro/jboss-3.0/jmx/src/main/org/jboss/mx/loading/CVS
and ./CVS
diff -u -N
/home/pra/src/rw/jboss-versions/3.0.x/ro/jboss-3.0/jmx/src/main/org/jboss/mx/loading/DelegatingLoaderRepository.java
./DelegatingLoaderRepository.java
---
/home/pra/src/rw/jboss-versions/3.0.x/ro/jboss-3.0/jmx/src/main/org/jboss/mx/loading/DelegatingLoaderRepository.java
Thu Jan 1 01:00:00 1970
+++ ./DelegatingLoaderRepository.java Mon Feb 17 13:17:01 2003
@@ -0,0 +1,241 @@
+/*
+* JBoss, the OpenSource EJB server
+*
+* Distributable under LGPL license.
+* See terms of license at gnu.org.
+*/
+package org.jboss.mx.loading;
+
+import java.net.URL;
+import java.util.List;
+import java.util.HashSet;
+import java.util.Iterator;
+import javax.management.AttributeNotFoundException;
+import javax.management.InstanceNotFoundException;
+import javax.management.MBeanException;
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+import javax.management.ReflectionException;
+import javax.management.MBeanRegistration;
+
+import org.jboss.mx.logging.Logger;
+import org.jboss.mx.loading.LoadMgr.PkgClassLoader;
+import org.jboss.mx.server.ServerConstants;
+/**
+ * DelegatingLoaderRepository.java
+ *
+ *
+ * Created: Thu Feb 13 17:05:56 2003
+ *
+ * @author Peter Antman
+ * @version $Revision$ $Date$
+ */
+
+public class DelegatingLoaderRepository extends
HeirarchicalLoaderRepository3 implements
DelegatingLoaderRepositoryMBean,MBeanRegistration {
+ // Attributes
+ private static final Logger log =
Logger.getLogger(DelegatingLoaderRepository.class);
+ private static ObjectName DEFAULT_LOADER_NAME;
+ static
+ {
+ try
+ {
+ DEFAULT_LOADER_NAME = new
ObjectName(ServerConstants.DEFAULT_LOADER_NAME);
+ }
+ catch(Exception e)
+ {
+ log.error("Failed to initialize default loader name", e);
+ }
+ }
+ MBeanServer server;
+ List dependantReps;
+
+ /*
+ public DelegatingLoaderRepository() {
+
+ }
+ */
+ public DelegatingLoaderRepository(MBeanServer server)
+ throws AttributeNotFoundException, InstanceNotFoundException,
MBeanException, ReflectionException
+ {
+ this(server, DEFAULT_LOADER_NAME);
+ }
+ public DelegatingLoaderRepository(MBeanServer server, ObjectName
parentName)
+ throws AttributeNotFoundException, InstanceNotFoundException,
MBeanException, ReflectionException
+ {
+ super(server,parentName);
+ this.server = server;
+ }
+
+ // MBean registration - to get at the MBean server!
+ public ObjectName preRegister(MBeanServer server,
+ ObjectName name)
+ throws java.lang.Exception {
+ this.server = server;
+ return name;
+ }
+
+ public void postRegister(java.lang.Boolean registrationDone) {}
+
+ public void preDeregister()
+ throws java.lang.Exception {}
+
+ public void postDeregister() {}
+
+ public void setDependantRepositories(List repositories) {
+ this.dependantReps = repositories;
+ }
+
+ public List getDependantRepositories() {
+ return dependantReps;
+ }
+
+
+ /** Load a class using the repository class loaders.
+*
+* @param name The name of the class
+* @param resolve If true, the class will be resolved
+* @param scl The asking class loader
+* @return The loaded class
+* @throws ClassNotFoundException If the class could not be found.
+*/
+ public Class loadClass(String name, boolean resolve, ClassLoader
scl)
+ throws ClassNotFoundException
+ {
+ Class foundClass = null;
+ try {
+ foundClass = super.loadClass(name, resolve, scl);
+ } catch (ClassNotFoundException e) {} // end of try-catch
+
+ if ( foundClass == null && dependantReps != null) {
+ if (log.isTraceEnabled())
+log.trace("Looking up class in delegating repositories");
+ Iterator repNames = dependantReps.iterator();
+ while ( repNames.hasNext()) {
+try {
+ UnifiedLoaderRepository3 repository =
getRepository((ObjectName)repNames.next());
+ foundClass = repository.loadClass(name, resolve, scl);
+ if( foundClass != null )
+ return foundClass;
+} catch (Exception e) {
+ log.warn("Could not lookup delegating repository:"+e);
+} // end of try-catch
+
+ } // end of while ()
+
+
+ } // end of if ()
+
+ /* If we reach here, all of the classloaders currently in the VM
don't
+ know about the class
+ */
+ throw new ClassNotFoundException(name);
+ }
+
+
+ /** Find a resource from this repository. This first looks to this
+* repository and then the parent repository.
+
[JBoss-dev] Branch_3_2 fails with clean checkout
Using JDK1.4.1 on windows a clean checkout of Branch_3_2 the management module fails to build with the following error. Regards Jonas Partner [javac] Compiling 161 source files to C:\CVS-modules\manual\try2\jboss-3.2\m anagement\output\classes C:\CVS-modules\manual\try2\jboss-3.2\management\src\main\org\jboss\managemen t\j2 ee\factory\RARModuleFactory.java:12: package org.jboss.resource does not exist import org.jboss.resource.RARMetaData; ^ C:\CVS-modules\manual\try2\jboss-3.2\management\src\main\org\jboss\managemen t\j2 ee\factory\RARModuleFactory.java:39: cannot resolve symbol symbol : class RARMetaData location: class org.jboss.management.j2ee.factory.RARModuleFactory RARMetaData metaData = (RARMetaData) di.metaData; ^ C:\CVS-modules\manual\try2\jboss-3.2\management\src\main\org\jboss\managemen t\j2 ee\factory\RARModuleFactory.java:39: cannot resolve symbol symbol : class RARMetaData location: class org.jboss.management.j2ee.factory.RARModuleFactory RARMetaData metaData = (RARMetaData) di.metaData; ^ C:\CVS-modules\manual\try2\jboss-3.2\management\src\main\org\jboss\managemen t\j2 ee\factory\RARModuleFactory.java:65: cannot resolve symbol symbol : class RARMetaData location: class org.jboss.management.j2ee.factory.RARModuleFactory RARMetaData metaData = (RARMetaData) di.metaData; ^ C:\CVS-modules\manual\try2\jboss-3.2\management\src\main\org\jboss\managemen t\j2 ee\factory\RARModuleFactory.java:65: cannot resolve symbol symbol : class RARMetaData location: class org.jboss.management.j2ee.factory.RARModuleFactory RARMetaData metaData = (RARMetaData) di.metaData; ^ 5 errors BUILD FAILED file:C:/CVS-modules/manual/try2/jboss-3.2/management/build.xml:314: Compile fail ed; see the compiler error output for details. Total time: 2 minutes 35 seconds --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Dependant classloader repository
On Tue, 2003-02-18 at 20:08, David Jencks wrote:
> I don't yet understand what problem you are trying to solve. The problem I
> know of with the current deployment set up and LoaderRepositories is that
> the only package type you can specify a LoaderRepsository in is an .ear.
> This however is easy to fix without more kinds of LoaderRepositories. You
> can already add several .ears to the same named LoaderRespository and (if
> there are no bugs) redeploy each independently.
Could have been working but is not:
if(
di.repositoryName.equals(DeploymentInfo.DEFAULT_LOADER_REPOSITORY) ==
false )
{
log.debug("Destroying ear loader
repository:"+di.repositoryName);
try
{
this.server.unregisterMBean(di.repositoryName);
}
catch(Exception e)
{
log.warn("Failed to unregister ear loader repository", e);
}
}
The first ear to get redeployed will destroy the repository! And will
make the other ear:s *very* confused.
My experience is also that a component that gets its classloader swaped
under the hood without beeing properly redeployed will behave very
eratic. Thats why.
//Peter
> I don't know if all
> dependencies between .ears are properly taken care of.
>
> What will having a deeper hierarchy of LoaderRepositories get you? I don't
> understand the situation in which this would be useful.
>
> Also, I am planning on moving the dependency computatations out of
> ServiceController and into an mbean interceptor (with some global
> supporting objects).
>
> thanks
> david jencks
>
>
>
> On 2003.02.18 13:51 Peter Antman wrote:
> >
> >
> > Hi,
> > I would like to share some ideas about extensions to the current
> > classloader to see if I am totally on the wrong track and if it
> > perhaps would be a welcome addition to JBoss.
> >
> > First I have to say that I still find the "new" classloader
> > architecture somewhat limiting. If you have the following two
> > conditions:
> >
> > 1. You do not want components/classes globally available in the
> >repository because this stops from implementation/interface
> >versioning.
> > 2. You want to be able to partition your stuff in several deployable
> >components (locally/remote), but which uses each other (EJB:s
> >calling EJB:s, MBeans calling MBeans (locally and through RMI),
> >MBeans calling EJB:s and EJB:s calling MBeans).
> >
> > The you basically have to do a couple of things:
> >
> > 1. Be very paranoid about what classes get stuffed into your
> >components.
> > 2. Up to the last classloader change stuff almost every class at the
> > global
> >level anyhow, through lib or a dynamic classloader deployer, and
> > after
> >the latest changes at least place all interfaces statically
> >available in the global classloader repository.
> >
> > To me this hinders one of the aspects that has always was dear to
> > me: hot redeploy.
> >
> > Here is an idea (with a working test implementation) to make these
> > obstacles possible to overcome:
> >
> > Create a repository which may delegate to other repositories (not just
> > a parent repository) and make this configurable in jboss-app.xml
> >
> > Create dependency checks so that lifecykling a component with a
> > repository which have dependent repositories will make also these
> > components "lifecyking".
> >
> > Here is the basic steps I took to create this:
> >
> > 1. Create a DelegatingLoaderRepository which extends
> >HeirarchicalLoaderRepository3. The delegating repository takes a
> >list of repositories to delegate to if the normal loading fails.
> >
> > 2. Factor out repository handling in EARDeployer, extends EARDeployer
> >with a DependantEARDeployer.
> >
> >EAR:s deployed through this new deployer may set up dependencies
> >between its own repository and the repositories of other
> >components. These other repositories must however also have been
> >created through the dependent deployer; because the repository must
> >be installed in the ServiceController.
> >
> >For a repository created through the DependantEARDeployer a
> >RepositoryProxy is created which will work as a proxy to track
> >dependency events from the ServiceController. The proxy also takes
> >the DeploymentInfo of the components; which makes it possible for
> >the proxy to redeploy its component!
> >
> > server.createMBean( "org.jboss.deployment.RepositoryProxy",
> > proxy);
> > serviceController.create(proxy,depends);
> > serviceController.start(proxy);
> > server.setAttribute( proxy, new
> > Attribute("DeploymentInfo",di));
> >
> >The repository is then added to ServiceController in the start face
> >of the deployment (so that all its subcomponents is available and
> >added to the repository).
> >
> >
> > So, how can this be used?
> >
> > Say we have component A and B. B needs to ca
