[JBoss-dev] JBoss 3.0 ClassLoader Architecture
An initial draft of a JBoss 3.0 ClassLoader Architecture whitepaper has been posted to the FAQ forum. See: http://jboss.org/forums/thread.jsp?forum=67&thread=15974 Scott Stark Chief Technology Officer JBoss Group, LLC ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CMP2.0 and CLOB: same as JAWS
Hello Dain, > Besides Oracle's drivers being a crap, for sure, yes. > the CLOB and all SQL 99 types > could use improvement. Supposedly Oracle's new 9.0.2 drivers fix most > of these problems. Fixing general Object persistence is the first think Great. > I will be working on after I finish the docs (this week), so I will look > at this then. I am even planing on putting a hack in just for Oracle's > BLOB problems, so I can also put one in for CLOBS. Normally I wouldn't > put a hack in for a vendor but Oracle it to huge. The flag of this > option will be some thing . =) OK, if you need some testing (or more accurate details on the problems I found), just tell me: I have a CMP and its associated Oracle DB that are already ready for testing. Cheers, Sacha ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Castor MBean in a JBoss 3.0 .sar
What is the structure of the sar? Does it contain
just the jboss-service.xml
descriptor along with the resource
files?
Scott StarkChief Technology
OfficerJBoss Group, LLC
- Original Message -
From:
Frederick N.
Brier
To: [EMAIL PROTECTED]
Sent: Sunday, May 19, 2002 4:33 PM
Subject: [JBoss-dev] Castor MBean in a
JBoss 3.0 .sar
I've been trying to update some of my app design and code from
JBoss 2.4.x to 3.0 and the new .sar approach. I need to specify the
Castor MBean inside a .sar. One issue that I've run into is the need to
convert the relative path of the CastorJDOImpl MBean's Configuration attribute
("file:./META-INF/database.xml") to a fully
specified, non-relative path (URI). This appears to be a design
limitation of Xerces. So the idea is to use the class loader for the
MBean which should be [???] created to reference the location of the expanded
.sar, no? The following was inserted into the CastorJDOImpl.java
MBean: URL confUrl =
Thread.currentThread().getContextClassLoader().getResource( _dbConf
);Where _dbConf is a String containing the Configuration
attribute with a value of "file:./META-INF/database.xml". Unfortunately, the
resource is never found. getSystemResource() also does not work.
Any suggestions or comments? Help, please.As an aside, I found
that the castor-jdo-plugin.jar build was commented out with a note that it
needed to be a .sar. That is not necessarily a requirement. To
support independent deployable application archives that would have different
tables and objects they were mapped to, Castor requires a separate
database.xml and mapping.xml for each one. So the thought is a Castor
MBean, along with a database.xml and mapping.xml file would be bundled in a
.sar along with any EJBs and their respective .jars. The
castor-jdo-plugin.jar would be copied into the jboss/lib directory along with
castor.jar. Then the jboss-service.xml could specify both (as depicted
below) to reference the required archives, and initialize an instance of the
CastorJDOImpl MBean with a different database.xml and mapping.xml for
each. Now I don't know if there are any other weird issues preventing
this, but I looked at the Castor code last year and it seemed to support
multiple databases.
file:META-INF/database.xml
jdo/aiabcommon
1
true
falsefalse
Oleg Nitz is the author of
the Castor MBean, and if he and no one else minds, and if I can figure out how
to get it to work, I'd like to make the modifications. Any
thoughts? Thank you again for the help.Fred.
[JBoss-dev] MBean ClassLoader ?revisited?
I just backtracked through the source, and read a bunch of messages of Mark Fleury, Scott Stark, and David Jencks. It sounded like Scott was saying in February (17th) that all the MBean(s) are using the same ClassLoader. But Mark and David were discussing in April ClassLoader(s) per MBean. So I am not sure where this all stands. It looks like the code is in place to allow any MBean to have its own classloader [MBeanServerImpl: invoke(), line 481]. It appears that an MBean ClassLoader must itself be an MBean and registered. If all this is working and I just don't understand how the element works, let me know. On the other hand, David just told me that I can't use a ClassLoader to find a resource. It would appear that all that needs to happen is that the SARDeployer create a ClassLoader MBean based on the DeploymentInfo/Inflated file system location and the element, and insert it at the beginning of the list of MBeans found in the jboss-service.xml file fed to the Service* classes in the org.jboss.system package. Then specify the ClassLoader MBean's ObjectName when invoking the MBeanServer.createMBean() method. The ServiceCreator.install() method actually makes the call to the MBeanServer to create the MBean [line 104-108], but has the parameter for the named ClassLoader commented out. This stuff is very intertwined. And I am not entirely sure that even if I've grasped it, I should attempt to complete the author's intent. But if y'all say go ahead, I'll give it a whirl, unless someone else is willing to step into the breach. Please give me some feedback. Thank you in advance. Fred. ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Castor MBean in a JBoss 3.0 .sar
On 2002.05.19 22:06:24 -0400 Frederick N. Brier wrote: > Wow. This could be a major bummer. Castor was only one of several > MBean(s) where I was going to use this technique. I have other MBeans > that > also needed to read their own XML files out of the .sar. I was > accomplishing this before (JBoss 2.4.x) with my DeploymentNotification > extension. I am aware of the idea that a .sar might not have any code in > > it. But isn't the purpose of the: > > > > XML element to define a ClassLoader for the archive? No, it's to make sure all these things are loaded before the xml mbean config is processed. One UnifiedClassloader per entry is created, also I believe one DeploymentInfo/entry. The MBean was not > loading due to missing classes until all the appropriate .jar(s) were > listed in the above statement. I thought it would be creating a > ClassLoader for the MBean(s) and contained .jar(s). MBeans don't get individual classloaders any more. The MBeanClassLoader was an idea to track the dependency between an mbean and its class, and it turned out to be easier to do without the extra classloader. Why would it not add > a > classpath to the root directory of where the .sar was expanded? Then any > > resources could be loaded out of the archive. There's still a [Unified] classloader for each DeploymentInfo. I think what you want to do is figure out which deployment info relates to where the database.xml is (such as by the convention that it is in the same sar, and including the name somewhere) and use its classloader directly. > > Also, it appears I seemed to have missed a big architectural change. > Where > is the directory where the .war(s), .ear(s), etc, are unpacked? Do they > no > longer need to be expanded? wars are sometimes unpacked by the web container. Everything else has its unpacking hidden by the njar url protocol handler. You may end up with a url something like njar:njar:jar:file://usr/java/mysar.sar^here/myrar.rar^lib/mylib.jar!org.me.myproject.myclass.class (I probably got some details wrong) I thought I saw code in the deployer where > they were still be unzipped? Help!! Because I was > using the Deployment Info to determine the actual temporary directory the > > archive was being unpacked in. From that, I was able to find the > required > XML resource files for my dynamic MBeans. If you can find the appropriate DeploymentInfo, you should be able to load resources from its classloader without needing to know where its package might or might not be. Does this make sense? david jencks > > Fred. > > At 08:44 PM 5/19/2002, you wrote: > >I don't think you are going to be able to use a classloader to try to > find > >something in the "same" deployment unit as a mbean config snippet. For > >instance, the mbean could be created in code rather than from a .sar, or > >created in a standalone xml file. > > > >I think you will either have to provide another means of locating the > >database.xml etc such as naming the deployment unit it is in or > incorporate > >the contents into your mbean configuration directly as xml element > valued > >attributes. > > > >Another possibility might be to make a CastorDeployer that could deploy > >.jar files containing META-INF/database.xml and mapping.xml files. > > > >In a somewhat different direction, Matthew Baird was working on > jca-ifying > >the OJB project, and seemed to have gotten pretty far. This might > provide > >an alternate deployment mechanism. He had several posts on the jca > forum. > > > >david jencks > > ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Castor MBean in a JBoss 3.0 .sar
Wow. This could be a major bummer. Castor was only one of several
MBean(s) where I was going to use this technique. I have other MBeans that
also needed to read their own XML files out of the .sar. I was
accomplishing this before (JBoss 2.4.x) with my DeploymentNotification
extension. I am aware of the idea that a .sar might not have any code in
it. But isn't the purpose of the:
XML element to define a ClassLoader for the archive? The MBean was not
loading due to missing classes until all the appropriate .jar(s) were
listed in the above statement. I thought it would be creating a
ClassLoader for the MBean(s) and contained .jar(s). Why would it not add a
classpath to the root directory of where the .sar was expanded? Then any
resources could be loaded out of the archive.
Also, it appears I seemed to have missed a big architectural change. Where
is the directory where the .war(s), .ear(s), etc, are unpacked? Do they no
longer need to be expanded? I thought I saw code in the deployer where
they were still be unzipped? Help!! Because I was
using the Deployment Info to determine the actual temporary directory the
archive was being unpacked in. From that, I was able to find the required
XML resource files for my dynamic MBeans.
Fred.
At 08:44 PM 5/19/2002, you wrote:
>I don't think you are going to be able to use a classloader to try to find
>something in the "same" deployment unit as a mbean config snippet. For
>instance, the mbean could be created in code rather than from a .sar, or
>created in a standalone xml file.
>
>I think you will either have to provide another means of locating the
>database.xml etc such as naming the deployment unit it is in or incorporate
>the contents into your mbean configuration directly as xml element valued
>attributes.
>
>Another possibility might be to make a CastorDeployer that could deploy
>.jar files containing META-INF/database.xml and mapping.xml files.
>
>In a somewhat different direction, Matthew Baird was working on jca-ifying
>the OJB project, and seemed to have gotten pretty far. This might provide
>an alternate deployment mechanism. He had several posts on the jca forum.
>
>david jencks
>
>On 2002.05.19 19:33:34 -0400 Frederick N. Brier wrote:
> > I've been trying to update some of my app design and code from JBoss
> > 2.4.x
> > to 3.0 and the new .sar approach. I need to specify the Castor MBean
> > inside a .sar. One issue that I've run into is the need to convert the
> > relative path of the CastorJDOImpl MBean's Configuration attribute
> > ("file:./META-INF/database.xml") to a fully specified, non-relative path
> > (URI). This appears to be a design limitation of Xerces. So the idea is
> >
> > to use the class loader for the MBean which should be [???] created to
> > reference the location of the expanded .sar, no? The following was
> > inserted into the CastorJDOImpl.java MBean:
> >
> > URL confUrl =
> > Thread.currentThread().getContextClassLoader().getResource( _dbConf );
> >
> > Where _dbConf is a String containing the Configuration attribute with a
> > value of "file:./META-INF/database.xml". Unfortunately, the resource is
> > never found. getSystemResource() also does not work. Any suggestions or
> > comments? Help, please.
> >
> > As an aside, I found that the castor-jdo-plugin.jar build was commented
> > out
> > with a note that it needed to be a .sar. That is not necessarily a
> > requirement. To support independent deployable application archives that
> >
> > would have different tables and objects they were mapped to, Castor
> > requires a separate database.xml and mapping.xml for each one. So the
> > thought is a Castor MBean, along with a database.xml and mapping.xml file
> >
> > would be bundled in a .sar along with any EJBs and their respective
> > .jars. The castor-jdo-plugin.jar would be copied into the jboss/lib
> > directory along with castor.jar. Then the jboss-service.xml could
> > specify
> > both (as depicted below) to reference the required archives, and
> > initialize
> > an instance of the CastorJDOImpl MBean with a different database.xml and
> > mapping.xml for each. Now I don't know if there are any other weird
> > issues
> > preventing this, but I looked at the Castor code last year and it seemed
> > to
> > support multiple databases.
> >
> >
> >
> >
> >
> > > code="org.jboss.jdo.castor.CastorJDOImpl"
> > name="DefaultDomain:service=CastorJDO,name=AIAB-Common">
> > file:META-INF/database.xml
> > jdo/aiabcommon
> > 1
> > true
> > false
> > false
> >
> >
> >
> >
> > Oleg Nitz is the author of the Castor MBean, and if he and no one else
> > minds, and if I can figure out how to get it to work, I'd like to make
> > the
> > modifications. Any thoughts? Thank you again for the help.
> >
> > Fred.
> >
> > I've been trying to update some of my app design and code from JBoss
> > 2.4.x to 3.0 and the new .sar approach. I need t
Re: [JBoss-dev] Jetty NPE on undeployment of jbosstest-web
I'll look at this tomorrow. Jules Scott M Stark wrote: > When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run against > the 3.0 branch the undeployment of the war is causing the NPE shown here: > > 17:38:01,062 INFO [MainDeployer] Undeployed > file:/D:/usr/local/src/cvsroot/JBos > s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear > 17:38:02,656 ERROR [STDERR] java.lang.NullPointerException > 17:38:02,656 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHandler$Cont > ext.getResource(ServletHandler.java:910) > 17:38:02,671 ERROR [STDERR] at > org.apache.jasper.JspEngineContext.getResourc > e(JspEngineContext.java:366) > 17:38:02,671 ERROR [STDERR] at > org.apache.jasper.compiler.JspCompiler.isOutD > ated(JspCompiler.java:179) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.compiler.Compiler.compile(C > ompiler.java:121) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.loadJSP( > JspServlet.java:557) > 17:38:02,687 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServl > etWrapper.loadIfNecessary(JspServlet.java:177) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServl > etWrapper.service(JspServlet.java:189) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.serviceJ > spFile(JspServlet.java:382) > 17:38:02,703 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.service( > JspServlet.java:474) > 17:38:02,703 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpSe > rvlet.java:853) > 17:38:02,703 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHolder.handl > e(ServletHolder.java:326) > 17:38:02,718 ERROR [STDERR] at > org.mortbay.jetty.servlet.Dispatcher.dispatch > (Dispatcher.java:259) > 17:38:02,718 ERROR [STDERR] at > org.mortbay.jetty.servlet.Dispatcher.include( > Dispatcher.java:171) > 17:38:02,718 ERROR [STDERR] at > org.apache.jasper.runtime.JspRuntimeLibrary.i > nclude(JspRuntimeLibrary.java:820) > 17:38:02,718 ERROR [STDERR] at > org.apache.jsp.include_0005fejb$jsp._jspServi > ce(include_0005fejb$jsp.java:61) > 17:38:02,718 ERROR [STDERR] at > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) > 17:38:02,718 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja > va:202) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) > 17:38:02,734 ERROR [STDERR] at > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) > 17:38:02,734 ERROR [STDERR] at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > 17:38:02,734 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHolder.handleServletHolder.java:326) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:595) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpContext.handle(HttpContext.java:1357) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpContext.handle(HttpContext.java:1309) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpServer.service(HttpServer.java:744) > 17:38:02,750 ERROR [STDERR] at > org.jboss.jetty.Jetty.service(Jetty.java:525) > 17:38:02,750 ERROR [STDERR] at > org.mortbay.http.HttpConnection.service(HttpConnection.java:743) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) > 17:38:02,765 ERROR [STDERR] at > org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) > 17:38:02,765 ERROR [STDERR] at java.lang.Thread.run(Thread.java:479) > 17:38:02,781 WARN [Jetty] WARNING: Servlet Exception for > /jbosstest/restricted/ > include_ejb.jsp > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > ___ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.n
Re: [JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
You may have to explicity `shutdown.sh --server localhost` or `shutdown.sh --shutdown` when working from HEAD, as help will be displayed with no arguments. --jason Quoting [EMAIL PROTECTED]: > > = > ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= > = > > JAVA VERSION DETAILS > java version "1.3.1" > Java(TM) 2 Runtime Environment, Standard Edition (build > Blackdown-1.3.1-02a-FCS) > Java HotSpot(TM) Client VM (build Blackdown-1.3.1_02a-FCS, mixed mode) > > = > > HERE ARE THE LAST 50 LINES OF THE LOG FILE > > Hello, > > The org.jboss.Shutdown class does not seem to work. > > That is, the jboss_redhat_init.sh script called it and the jboss > server did not stop... > > Please could we get this fixed... > > Or tell me what I should be calling to get the server shutdown... > > Now I will return to the old faithful method - "kill -9" > > See ya, > Chris > > PS This is automated - just to make it really annoying... > > ___ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-02a-FCS) Java HotSpot(TM) Client VM (build Blackdown-1.3.1_02a-FCS, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 20-May-2002
Number of tests run: 736 Successful tests: 577 Errors:155 Failures: 4 [time of test: 20 May 2002 2:39 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] Useful resources: - http://lubega.com/testarchive/blackdown_jdk131_02_native for the junit report of this test. - http://lubega.com/testarchive/blackdown_jdk131_02_native/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)) = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 20-May-2002
Number of tests run: 736 Successful tests: 576 Errors:155 Failures: 5 [time of test: 20 May 2002 1:39 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] Useful resources: - http://lubega.com/testarchive/ibm_jdk13_20020124 for the junit report of this test. - http://lubega.com/testarchive/ibm_jdk13_20020124/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Castor MBean in a JBoss 3.0 .sar
I don't think you are going to be able to use a classloader to try to find
something in the "same" deployment unit as a mbean config snippet. For
instance, the mbean could be created in code rather than from a .sar, or
created in a standalone xml file.
I think you will either have to provide another means of locating the
database.xml etc such as naming the deployment unit it is in or incorporate
the contents into your mbean configuration directly as xml element valued
attributes.
Another possibility might be to make a CastorDeployer that could deploy
.jar files containing META-INF/database.xml and mapping.xml files.
In a somewhat different direction, Matthew Baird was working on jca-ifying
the OJB project, and seemed to have gotten pretty far. This might provide
an alternate deployment mechanism. He had several posts on the jca forum.
david jencks
On 2002.05.19 19:33:34 -0400 Frederick N. Brier wrote:
> I've been trying to update some of my app design and code from JBoss
> 2.4.x
> to 3.0 and the new .sar approach. I need to specify the Castor MBean
> inside a .sar. One issue that I've run into is the need to convert the
> relative path of the CastorJDOImpl MBean's Configuration attribute
> ("file:./META-INF/database.xml") to a fully specified, non-relative path
> (URI). This appears to be a design limitation of Xerces. So the idea is
>
> to use the class loader for the MBean which should be [???] created to
> reference the location of the expanded .sar, no? The following was
> inserted into the CastorJDOImpl.java MBean:
>
> URL confUrl =
> Thread.currentThread().getContextClassLoader().getResource( _dbConf );
>
> Where _dbConf is a String containing the Configuration attribute with a
> value of "file:./META-INF/database.xml". Unfortunately, the resource is
> never found. getSystemResource() also does not work. Any suggestions or
> comments? Help, please.
>
> As an aside, I found that the castor-jdo-plugin.jar build was commented
> out
> with a note that it needed to be a .sar. That is not necessarily a
> requirement. To support independent deployable application archives that
>
> would have different tables and objects they were mapped to, Castor
> requires a separate database.xml and mapping.xml for each one. So the
> thought is a Castor MBean, along with a database.xml and mapping.xml file
>
> would be bundled in a .sar along with any EJBs and their respective
> .jars. The castor-jdo-plugin.jar would be copied into the jboss/lib
> directory along with castor.jar. Then the jboss-service.xml could
> specify
> both (as depicted below) to reference the required archives, and
> initialize
> an instance of the CastorJDOImpl MBean with a different database.xml and
> mapping.xml for each. Now I don't know if there are any other weird
> issues
> preventing this, but I looked at the Castor code last year and it seemed
> to
> support multiple databases.
>
>
>
>
>
> code="org.jboss.jdo.castor.CastorJDOImpl"
> name="DefaultDomain:service=CastorJDO,name=AIAB-Common">
> file:META-INF/database.xml
> jdo/aiabcommon
> 1
> true
> false
> false
>
>
>
>
> Oleg Nitz is the author of the Castor MBean, and if he and no one else
> minds, and if I can figure out how to get it to work, I'd like to make
> the
> modifications. Any thoughts? Thank you again for the help.
>
> Fred.
>
> I've been trying to update some of my app design and code from JBoss
> 2.4.x to 3.0 and the new .sar approach. I need to specify the
> Castor MBean inside a .sar. One issue that I've run into is the
> need to convert the relative path of the CastorJDOImpl MBean's
> Configuration attribute
> (" eudora="autourl">file:./META-INF/database. href="file:META-INF\database.xml" eudora="autourl">xml")
> to a fully specified, non-relative path (URI). This appears to be a
> design limitation of Xerces. So the idea is to use the class loader
> for the MBean which should be [???] created to reference the location of
> the expanded .sar, no? The following was inserted into the
> CastorJDOImpl.java MBean:
>
> URL confUrl =
> Thread.currentThread().getContextClassLoader().getResource( _dbConf
> );
>
> Where _dbConf is a String containing the Configuration attribute
> with a value of
> " eudora="autourl">file:./META-INF/database.xml".
> Unfortunately, the resource is never found. getSystemResource()
> also does not work. Any suggestions or comments? Help,
> please.
>
> As an aside, I found that the castor-jdo-plugin.jar build was commented
> out with a note that it needed to be a .sar. That is not
> necessarily a requirement. To support independent deployable
> application archives that would have different tables and objects they
> were mapped to, Castor requires a separate database.xml and mapping.xml
> for each one. So the thought is a Castor MBean, along with a
> database.xml and mapping.xml file would be bundled in a .sar along with
[JBoss-dev] Jetty NPE on undeployment of jbosstest-web
When the org.jboss.test.web.test.WebIntegrationUnitTestCase is run against the 3.0 branch the undeployment of the war is causing the NPE shown here: 17:38:01,062 INFO [MainDeployer] Undeployed file:/D:/usr/local/src/cvsroot/JBos s3.0/jboss-all/testsuite/output/lib/jbosstest-web.ear 17:38:02,656 ERROR [STDERR] java.lang.NullPointerException 17:38:02,656 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHandler$Cont ext.getResource(ServletHandler.java:910) 17:38:02,671 ERROR [STDERR] at org.apache.jasper.JspEngineContext.getResourc e(JspEngineContext.java:366) 17:38:02,671 ERROR [STDERR] at org.apache.jasper.compiler.JspCompiler.isOutD ated(JspCompiler.java:179) 17:38:02,687 ERROR [STDERR] at org.apache.jasper.compiler.Compiler.compile(C ompiler.java:121) 17:38:02,687 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.loadJSP( JspServlet.java:557) 17:38:02,687 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet$JspServl etWrapper.loadIfNecessary(JspServlet.java:177) 17:38:02,703 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet$JspServl etWrapper.service(JspServlet.java:189) 17:38:02,703 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.serviceJ spFile(JspServlet.java:382) 17:38:02,703 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.service( JspServlet.java:474) 17:38:02,703 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpSe rvlet.java:853) 17:38:02,703 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHolder.handl e(ServletHolder.java:326) 17:38:02,718 ERROR [STDERR] at org.mortbay.jetty.servlet.Dispatcher.dispatch (Dispatcher.java:259) 17:38:02,718 ERROR [STDERR] at org.mortbay.jetty.servlet.Dispatcher.include( Dispatcher.java:171) 17:38:02,718 ERROR [STDERR] at org.apache.jasper.runtime.JspRuntimeLibrary.i nclude(JspRuntimeLibrary.java:820) 17:38:02,718 ERROR [STDERR] at org.apache.jsp.include_0005fejb$jsp._jspServi ce(include_0005fejb$jsp.java:61) 17:38:02,718 ERROR [STDERR] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) 17:38:02,718 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 17:38:02,734 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:202) 17:38:02,734 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) 17:38:02,734 ERROR [STDERR] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) 17:38:02,734 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 17:38:02,734 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHolder.handleServletHolder.java:326) 17:38:02,750 ERROR [STDERR] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:595) 17:38:02,750 ERROR [STDERR] at org.mortbay.http.HttpContext.handle(HttpContext.java:1357) 17:38:02,750 ERROR [STDERR] at org.mortbay.http.HttpContext.handle(HttpContext.java:1309) 17:38:02,750 ERROR [STDERR] at org.mortbay.http.HttpServer.service(HttpServer.java:744) 17:38:02,750 ERROR [STDERR] at org.jboss.jetty.Jetty.service(Jetty.java:525) 17:38:02,750 ERROR [STDERR] at org.mortbay.http.HttpConnection.service(HttpConnection.java:743) 17:38:02,765 ERROR [STDERR] at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) 17:38:02,765 ERROR [STDERR] at org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) 17:38:02,765 ERROR [STDERR] at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145) 17:38:02,765 ERROR [STDERR] at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) 17:38:02,765 ERROR [STDERR] at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) 17:38:02,765 ERROR [STDERR] at java.lang.Thread.run(Thread.java:479) 17:38:02,781 WARN [Jetty] WARNING: Servlet Exception for /jbosstest/restricted/ include_ejb.jsp Scott Stark Chief Technology Officer JBoss Group, LLC ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.0 Branch tests-unit is back to 0 errors
The 3.0 branch. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Duarte Loreto" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, May 19, 2002 4:12 PM Subject: Re: [JBoss-dev] 3.0 Branch tests-unit is back to 0 errors >Hello! > > Does this mean we should checkout from CVS the Rel_3_0_0_7 branch or we can > continue checking out the Branch_3_0? > > By the way... Sorry I couldn't deliver the HP-UX tests Friday. I'll have > fresh new on Monday. > > Duarte "HappyGuy" Loreto > > "Don't worry, be happy!" > > >From: "Scott M Stark" <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: <[EMAIL PROTECTED]> > >Subject: [JBoss-dev] 3.0 Branch tests-unit is back to 0 errors > >Date: Sat, 18 May 2002 16:11:30 -0700 > > > >The 3.0 branch tests-unit is running cleanly on w2k with JDK 1.3.1_03. > >This has been tagged with Rel_3_0_0_7 > > > > > >Scott Stark > >Chief Technology Officer > >JBoss Group, LLC > > > > > _ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > ___ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)) = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - "kill -9" See ya, Chris PS This is automated - just to make it really annoying... ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 20-May-2002
Number of tests run: 736 Successful tests: 576 Errors:155 Failures: 5 [time of test: 20 May 2002 0:39 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] Useful resources: - http://lubega.com/testarchive/ibm_jdk13_20010626 for the junit report of this test. - http://lubega.com/testarchive/ibm_jdk13_20010626/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Castor MBean in a JBoss 3.0 .sar
I've been trying to update some of my app design and code from JBoss
2.4.x to 3.0 and the new .sar approach. I need to specify the
Castor MBean inside a .sar. One issue that I've run into is the
need to convert the relative path of the CastorJDOImpl MBean's
Configuration attribute
("file:./META-INF/database.xml")
to a fully specified, non-relative path (URI). This appears to be a
design limitation of Xerces. So the idea is to use the class loader
for the MBean which should be [???] created to reference the location of
the expanded .sar, no? The following was inserted into the
CastorJDOImpl.java MBean:
URL confUrl =
Thread.currentThread().getContextClassLoader().getResource( _dbConf
);
Where _dbConf is a String containing the Configuration attribute
with a value of
"file:./META-INF/database.xml".
Unfortunately, the resource is never found. getSystemResource()
also does not work. Any suggestions or comments? Help,
please.
As an aside, I found that the castor-jdo-plugin.jar build was commented
out with a note that it needed to be a .sar. That is not
necessarily a requirement. To support independent deployable
application archives that would have different tables and objects they
were mapped to, Castor requires a separate database.xml and mapping.xml
for each one. So the thought is a Castor MBean, along with a
database.xml and mapping.xml file would be bundled in a .sar along with
any EJBs and their respective .jars. The castor-jdo-plugin.jar
would be copied into the jboss/lib directory along with castor.jar.
Then the jboss-service.xml could specify both (as depicted below) to
reference the required archives, and initialize an instance of the
CastorJDOImpl MBean with a different database.xml and mapping.xml for
each. Now I don't know if there are any other weird issues
preventing this, but I looked at the Castor code last year and it seemed
to support multiple databases.
file:META-INF/database.xml
jdo/aiabcommon
1
true
false
false
Oleg Nitz is the author of the Castor MBean, and if he and no one
else minds, and if I can figure out how to get it to work, I'd like to
make the modifications. Any thoughts? Thank you again for the
help.
Fred.
[JBoss-dev] Talk on IIOP support in JBoss
For those in South America this coming week: on May 23 (4:30PM) I will be an invited speaker at the "Objetos 6006" conference, in Sao Paulo, Brazil. This event is jointly organized by three Sao Paulo user groups -- the OO/UML user group, the Java user group, and the CORBA user group. More info (in Portuguese): http://www.objetos6006.com.br/palestras.htm The conference schedule is in http://www.objetos6006.com.br/palestras.htm Cheers, Francisco ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.0 Branch tests-unit is back to 0 errors
Hello! Does this mean we should checkout from CVS the Rel_3_0_0_7 branch or we can continue checking out the Branch_3_0? By the way... Sorry I couldn't deliver the HP-UX tests Friday. I'll have fresh new on Monday. Duarte "HappyGuy" Loreto "Don't worry, be happy!" >From: "Scott M Stark" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: [JBoss-dev] 3.0 Branch tests-unit is back to 0 errors >Date: Sat, 18 May 2002 16:11:30 -0700 > >The 3.0 branch tests-unit is running cleanly on w2k with JDK 1.3.1_03. >This has been tagged with Rel_3_0_0_7 > > >Scott Stark >Chief Technology Officer >JBoss Group, LLC > _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JRMP and IIOP invocations to the same container...
are now working in 3.1 (CVS HEAD). Marc: your vision is real!!! Even concurrent JRMP and IIOP invocations appear to be working fine. I have committed yet another version of the hello test (hellojrmpiiop) to demonstrate this. Here is a summary of the recent changes on the IIOP stuff in 3.1: - The EJB-specific IIOPContainerInvoker is gone. Its functionality is now split between a generic IIOPInvoker MBean and an EJB-specific IORFactory, which is the IIOP version of a ProxyFactory. - These two guys interact in the following way: the IORFactory registers CORBA servants with the IIOPInvoker, which returns to the IORFactory reference factories the IORFactory uses to create CORBA references. Two new interfaces are involved: ServantRegistry and ReferenceFactory, both implemented by objects provided/returned by the IIOPInvoker. - An IORFactory is associated to a given container. It creates two CORBA servants: an EjbHomeCorbaServant and an EjbObjectCorbaServant. Both are thin wrappers that forward invocations to the container, through the JBoss MBean server. - Other CORBA reference factories (which don't need to be EJB-specific) may also use the IIOPInvoker. As an example, the in-VM CORBA naming service in 3.1 has been modified to register its servants with the IIOPInvoker. A next step would be an IIOP Java proxy factory that talks to the IIOPinvoker. (Any volunteers?...) - The CORBA naming service has been taken off the CORBA ORB service and is now a separate MBean. - IIOP-specific container configurations are gone. Now you just specify the iiop . - The of an IORFactory takes the following sub-elements (see iiop proxy binding in standardjboss.xml): - : Moved from the container configuration. Must contain org.jboss.iiop.WebCL. - : May be shared (a single POA shared among all servants bound to a ServantRegistry) or per-servant (a separate POA is created for each servant bound to a ServantRegistry). The default value in the iiop in standardjboss.xml is per-servant. - : If true, EJBHome IORs are registered with the JBoss JNP naming service in addition to being registered with the CORBA naming service. If false EJBHome IORs are registered only with the CORBA naming service. The default value in the iiop in standardjboss.xml is true. - : Only meaningful it the previous element is true. Specifies the JNP naming context EJBHome IORs will be bound to. If absent, EJB IORs will be bount to the root JNP naming context. The default value in the iiop in standardjboss.xml is iiop. To clarify the last two config elements: in the hellojrmpiiop test, the JRMP reference to the EJBHome is bound to "helloworld/Hello" in the JNP naming service. The EJBHome IOR is bound to "helloworld/Hello" in the CORBA naming service and to "iiop/helloworld/Hello" in the JNP naming service (because is true and is iiop). Let me know what you think of this arrangement. Suggestions/ideas are very welcome. And please let me know of any problems. This stuff is built upon Bill's great work on multiple invokers. It is also a consequence of very enlightening discussions with Marc and Bill. Thanks, guys! Best, Francisco ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 and CLOB: same as JAWS
I have been thinking about this for a while, but I've been trying to put off expanding the jca wrapper stuff (I have a bunch of ideas in this area; most likely 4.0 stuff). I don't use Oracle at all. -dain David Jencks wrote: > As slightly less of a hack, how about writing an oracle-driver specific jca > wrapper that takes care of Oracle non-spec compliance? > > You need to modify prepared statement, right? How about the resultset? So > far I haven't wrapped the result set but have been asked to by 2 people. > > BTW do either of you have oracle xa working with jboss 3? > > Thanks > david jencks > > > On 2002.05.19 16:33:22 -0400 Dain Sundstrom wrote: > >>Sacha, >> >>Besides Oracle's drivers being a crap, the CLOB and all SQL 99 types >>could use improvement. Supposedly Oracle's new 9.0.2 drivers fix most >>of these problems. Fixing general Object persistence is the first think >>I will be working on after I finish the docs (this week), so I will look >>at this then. I am even planing on putting a hack in just for Oracle's >>BLOB problems, so I can also put one in for CLOBS. Normally I wouldn't >>put a hack in for a vendor but Oracle it to huge. The flag of this >>option will be some thing . =) >> >>-dain >> >>Sacha Labourey wrote: >> >> >>>Hello Dain, >>> >>>I had to look at the JAWS code and how it handled CLOB and have found >>>numerous issues (see my previous post on jboss-dev). >>> >>>I've quickly taken a look at the new ejb2.0 code you implemented and >>> >>saw >> >>>that you're using about the same code for CLOBs. Thus, I think that >>> >>your >> >>>code will have trouble handling CLOBs. >>> >>>Some quick info I found by looking at jaws: >>> >>>- the "read-CLOB" code is actually never used: the code is there but is >>>never reached. The code tests if the field is a string and try to read >>> >>it >> >>>from the recordset by using getString. In Oracle, for example, this >>> >>will >> >>>return null and not raise an exception => null is assigned to the CMP >>> >>field >> >>>even if the CLOB contains data. A check should be added to use the CLOB >>> >>code >> >>>if Type.CLOB has been assigned as the JDBC type of the CMP field. >>> >>>- the "write-CLOB" code handles BLOB and CLOB in the same way => like >>> >>binary >> >>>content. This leads to several problems. >>>First, the String is wrapped in a MarshalledObject and transformed in a >>>byte[] then persisted in the database => the string that is persisted >>> >>in the >> >>>database is unreadable by any other application (because it is >>> >>Java-encoded) >> >>>and no SQL Clob-operators can be used in queries. >>>Second, and this is more an Oracle issue, we have trouble sending back >>> >>a >> >>>Clob to the driver. Either we use preparedStatement.setClob or >>>preparedStatement.setCharacterStream. I've tried to modify JAWS so it >>> >>uses >> >>>preparedStatement.setClob and I have coded a new class that implements >>>java.sql.Clob (and containing the String) that I send to the >>>preparedStatement. Here, we have an Oracle problem: this driver expects >>> >>a >> >>>oracle.sql.Clob object (and is thus not spec compliant): a >>> >>CastException >> >>>occurs. So it doesn't work. Secondly, I've used setCharacterStream. I >>> >>think >> >>>it is the best solution. Nevertheless, we still have a problem: it will >>> >>only >> >>>work with Oracle OCI driver, not the thin driver!!! So I haven't been >>> >>able >> >>>to test the code (but at least it works with thin when strings are < >>> >>2k). >> >>>What do you think? >>> >>>Cheers, >>> >>> >>> >>> Sacha >>> >>> >>>___ >>>Hundreds of nodes, one monster rendering program. >>>Now that's a super model! Visit http://clustering.foundries.sf.net/ >>> >>>___ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >> >> >>___ >>Hundreds of nodes, one monster rendering program. >>Now that's a super model! Visit http://clustering.foundries.sf.net/ >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> >> > > ___ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing l
Re: [JBoss-dev] CMP2.0 and CLOB: same as JAWS
As slightly less of a hack, how about writing an oracle-driver specific jca wrapper that takes care of Oracle non-spec compliance? You need to modify prepared statement, right? How about the resultset? So far I haven't wrapped the result set but have been asked to by 2 people. BTW do either of you have oracle xa working with jboss 3? Thanks david jencks On 2002.05.19 16:33:22 -0400 Dain Sundstrom wrote: > Sacha, > > Besides Oracle's drivers being a crap, the CLOB and all SQL 99 types > could use improvement. Supposedly Oracle's new 9.0.2 drivers fix most > of these problems. Fixing general Object persistence is the first think > I will be working on after I finish the docs (this week), so I will look > at this then. I am even planing on putting a hack in just for Oracle's > BLOB problems, so I can also put one in for CLOBS. Normally I wouldn't > put a hack in for a vendor but Oracle it to huge. The flag of this > option will be some thing . =) > > -dain > > Sacha Labourey wrote: > > > Hello Dain, > > > > I had to look at the JAWS code and how it handled CLOB and have found > > numerous issues (see my previous post on jboss-dev). > > > > I've quickly taken a look at the new ejb2.0 code you implemented and > saw > > that you're using about the same code for CLOBs. Thus, I think that > your > > code will have trouble handling CLOBs. > > > > Some quick info I found by looking at jaws: > > > > - the "read-CLOB" code is actually never used: the code is there but is > > never reached. The code tests if the field is a string and try to read > it > > from the recordset by using getString. In Oracle, for example, this > will > > return null and not raise an exception => null is assigned to the CMP > field > > even if the CLOB contains data. A check should be added to use the CLOB > code > > if Type.CLOB has been assigned as the JDBC type of the CMP field. > > > > - the "write-CLOB" code handles BLOB and CLOB in the same way => like > binary > > content. This leads to several problems. > > First, the String is wrapped in a MarshalledObject and transformed in a > > byte[] then persisted in the database => the string that is persisted > in the > > database is unreadable by any other application (because it is > Java-encoded) > > and no SQL Clob-operators can be used in queries. > > Second, and this is more an Oracle issue, we have trouble sending back > a > > Clob to the driver. Either we use preparedStatement.setClob or > > preparedStatement.setCharacterStream. I've tried to modify JAWS so it > uses > > preparedStatement.setClob and I have coded a new class that implements > > java.sql.Clob (and containing the String) that I send to the > > preparedStatement. Here, we have an Oracle problem: this driver expects > a > > oracle.sql.Clob object (and is thus not spec compliant): a > CastException > > occurs. So it doesn't work. Secondly, I've used setCharacterStream. I > think > > it is the best solution. Nevertheless, we still have a problem: it will > only > > work with Oracle OCI driver, not the thin driver!!! So I haven't been > able > > to test the code (but at least it works with thin when strings are < > 2k). > > > > What do you think? > > > > Cheers, > > > > > > > > Sacha > > > > > > ___ > > Hundreds of nodes, one monster rendering program. > > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 and CLOB: same as JAWS
Sacha, Besides Oracle's drivers being a crap, the CLOB and all SQL 99 types could use improvement. Supposedly Oracle's new 9.0.2 drivers fix most of these problems. Fixing general Object persistence is the first think I will be working on after I finish the docs (this week), so I will look at this then. I am even planing on putting a hack in just for Oracle's BLOB problems, so I can also put one in for CLOBS. Normally I wouldn't put a hack in for a vendor but Oracle it to huge. The flag of this option will be some thing . =) -dain Sacha Labourey wrote: > Hello Dain, > > I had to look at the JAWS code and how it handled CLOB and have found > numerous issues (see my previous post on jboss-dev). > > I've quickly taken a look at the new ejb2.0 code you implemented and saw > that you're using about the same code for CLOBs. Thus, I think that your > code will have trouble handling CLOBs. > > Some quick info I found by looking at jaws: > > - the "read-CLOB" code is actually never used: the code is there but is > never reached. The code tests if the field is a string and try to read it > from the recordset by using getString. In Oracle, for example, this will > return null and not raise an exception => null is assigned to the CMP field > even if the CLOB contains data. A check should be added to use the CLOB code > if Type.CLOB has been assigned as the JDBC type of the CMP field. > > - the "write-CLOB" code handles BLOB and CLOB in the same way => like binary > content. This leads to several problems. > First, the String is wrapped in a MarshalledObject and transformed in a > byte[] then persisted in the database => the string that is persisted in the > database is unreadable by any other application (because it is Java-encoded) > and no SQL Clob-operators can be used in queries. > Second, and this is more an Oracle issue, we have trouble sending back a > Clob to the driver. Either we use preparedStatement.setClob or > preparedStatement.setCharacterStream. I've tried to modify JAWS so it uses > preparedStatement.setClob and I have coded a new class that implements > java.sql.Clob (and containing the String) that I send to the > preparedStatement. Here, we have an Oracle problem: this driver expects a > oracle.sql.Clob object (and is thus not spec compliant): a CastException > occurs. So it doesn't work. Secondly, I've used setCharacterStream. I think > it is the best solution. Nevertheless, we still have a problem: it will only > work with Oracle OCI driver, not the thin driver!!! So I haven't been able > to test the code (but at least it works with thin when strings are < 2k). > > What do you think? > > Cheers, > > > > Sacha > > > ___ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-558052 ] ENC is not set in ServletContextListener
Bugs item #558052, was opened at 2002-05-19 22:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=558052&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Bogdan Ghidireac (ghidi) Assigned to: Nobody/Anonymous (nobody) Summary: ENC is not set in ServletContextListener Initial Comment: I want to use ServletContextListener to create an EJB used to initialize my application. When I am trying to lookup my bean, I get a javax.naming.NameNotFoundException: env not bound I am using JBoss3.0.0RC2-Jetty. With JBoss3.0.0RC2-tomcat it is working fine. Regards, Bogdan -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=558052&group_id=22866 ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 3.0 Branch tests-unit is back to 0 errors
FYI: The following is on WinNT 4.0 SP6: I just got Rel_3_0_0_7 from CVS and ran the test suite on it, once using Sun JDK1.3.1_02 (gave 1 failure) and then 1.3.1_03 (I did a clobber on jboss-all and testsuite and cleaned the tmp and db directories between the tests). This 1.3.1_03 test resulted in: Successful tests: 591 Errors:1 Failures: 1 The one, that occurred in both tests is (copied from HTML report): testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) Error Failed to readURL, ex=Connection refused: connect java.io.IOException: Failed to readURL, ex=Connection refused: connect <> The second one (did not occur with JDK1.3.1_02) is: testFillToMin(org.jboss.test.jca.test.BaseConnectionManagerUnitTestCase) Failure Wrong number of connections counted: 1 ... at org.jboss.test.jca.test.BaseConnectionManagerUnitTestCase.testFillToMin( BaseConnectionManagerUnitTestCase.java:155) ... Running the testsuite again without restarting the JBoss server results in: Successful tests: 590 Errors:2 Failures: 1 This time the "testPassivationBySize(org.jboss.test.cts.test.StatefulSessionUnitTestCa se) Failure sessionBean1 WasPassivated" (at StatefulSessionUnitTestCase.java:104) fails as well as the custom socket based JRMP tests (for known reasons). Running the testsuite a third time results in a testFillToMin failure, while the testPassivationBySize succeeds. Running the testsuite a fourth time results in testFillToMin success, but now "testLocalInterfacePassivation(org.jboss.test.cts.test.StatefulSessionUn itTestCase) Failure N/A" (StatefulSessionUnitTestCase.java:75) occurs. Running the testsuite a fifth time results in "testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) Error Failed to readURL, ex=Connection refused: connect", and the errors from the fourth run remain, making Successful tests: 588 Errors:4 Failures: 1 Except from that JBoss 3.0.0 starts looking really good! Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Sunday, May 19, 2002 01:12 To: [EMAIL PROTECTED] Subject: [JBoss-dev] 3.0 Branch tests-unit is back to 0 errors The 3.0 branch tests-unit is running cleanly on w2k with JDK 1.3.1_03. This has been tagged with Rel_3_0_0_7 Scott Stark Chief Technology Officer JBoss Group, LLC ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Aaron Arbery/FIRSY/Australia/MCKINSEY is out of the office.
I will be out of the office starting 20/05/2002 and will not return until 27/05/2002. I will respond to your message when I return. +-+ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. +-+ ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CMP2.0 and CLOB: same as JAWS
Hello Dain, I had to look at the JAWS code and how it handled CLOB and have found numerous issues (see my previous post on jboss-dev). I've quickly taken a look at the new ejb2.0 code you implemented and saw that you're using about the same code for CLOBs. Thus, I think that your code will have trouble handling CLOBs. Some quick info I found by looking at jaws: - the "read-CLOB" code is actually never used: the code is there but is never reached. The code tests if the field is a string and try to read it from the recordset by using getString. In Oracle, for example, this will return null and not raise an exception => null is assigned to the CMP field even if the CLOB contains data. A check should be added to use the CLOB code if Type.CLOB has been assigned as the JDBC type of the CMP field. - the "write-CLOB" code handles BLOB and CLOB in the same way => like binary content. This leads to several problems. First, the String is wrapped in a MarshalledObject and transformed in a byte[] then persisted in the database => the string that is persisted in the database is unreadable by any other application (because it is Java-encoded) and no SQL Clob-operators can be used in queries. Second, and this is more an Oracle issue, we have trouble sending back a Clob to the driver. Either we use preparedStatement.setClob or preparedStatement.setCharacterStream. I've tried to modify JAWS so it uses preparedStatement.setClob and I have coded a new class that implements java.sql.Clob (and containing the String) that I send to the preparedStatement. Here, we have an Oracle problem: this driver expects a oracle.sql.Clob object (and is thus not spec compliant): a CastException occurs. So it doesn't work. Secondly, I've used setCharacterStream. I think it is the best solution. Nevertheless, we still have a problem: it will only work with Oracle OCI driver, not the thin driver!!! So I haven't been able to test the code (but at least it works with thin when strings are < 2k). What do you think? Cheers, Sacha ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Foe-Deployer
Hi Andreas, now I have utility that takes .wljar as input parameter and converts it to .jar. It works this way: - Read next jar entry from wljar; - If current jar entry is an xml file: Look in classpath for xsl file with name .xsl; If xsl file not found, copy entry and read next from wljar; Look in classpath for output properties file for xslt with name -output.properties; Transform xml file with xsl applying output properties (if were found); Create new entry and write to resulting jar; - If current entry isn't xml file, copy entry to resulting jar. For example if we need to transform weblogic-ejb-jar.xml we have to put in th classpath weblogic-ejb-jar.xsl and, optionally, weblogic-ejb-jar-output.properties. Output properties file looks like this: # Output properties for XSL transformations. indent=yes method=xml doctype-public=-//JBoss//DTD JBOSS//EN doctype-system=http://www.jboss.org/j2ee/dtd/jboss.dtd # name for transformed entry newname=META-INF/jboss.xml If newname isn't specified, transformed entry will have the same name. -Original Message- From: "Andreas Schaefer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Thu, 16 May 2002 00:10:30 -0700 Subject: [JBoss-dev] Foe-Deployer > Hi Geeks > > To start the entire tool that is my idea: > - we use a special extension for the foe-deployment-units >like "myWLApplication.wljar" etc. for now > > then foe-deployer will: > - accept these deployments > - transform the vendor-specific DDs to JBoss specific DDs >by using XSLT > - incorporate these JBoss DDs into the archive > - rename the archive to the correct extension and resend it >to the Main-Deployer for JBoss deployment > I will write the foe-deployer until next Monday (will be in > Dallas on the weekend bragging about JBoss). > > ToDo List: > - concept how to use XSLT > - list of elements in the WL DDs we convert in the first >release (plain-simple WL-application with simple CMP) > - one or more WL applications to test tool with DB scripts etc. >(using Hypersonic) > - list of possible problems to look out > > And finally have fun > > x > Andreas Schaefer > Senior Consultant > JBoss Group, LLC > x > > > > ___ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > - ðÏÌÕÞÉÔÅ ÂÅÓÐÌÁÔÎÙÊ ÐÏÞÔÏ×ÙÊ ÑÝÉË @ukr.net ÎÁ http://freemail.ukr.net ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
