[JBoss-dev] CVS update: newsite/src/docs/pictures jboss.survey.ear
User: schaefera Date: 01/09/05 00:10:56 Modified:src/docs/pictures jboss.survey.ear Log: Update version of JBoss Survey Revision ChangesPath 1.2 +326 -257 newsite/src/docs/pictures/jboss.survey.ear Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: newsite/src/docs/pictures jboss.survey.ear
Where does this come from? How does it deploy... does it deploy? What is it doing in pictures/? =] --jason On Wed, 5 Sep 2001, Andreas Mad Schaefer wrote: User: schaefera Date: 01/09/05 00:10:56 Modified:src/docs/pictures jboss.survey.ear Log: Update version of JBoss Survey Revision ChangesPath 1.2 +326 -257 newsite/src/docs/pictures/jboss.survey.ear Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs/howto howtovisualagedebug.xml
User: gropi Date: 01/09/05 01:37:55 Modified:src/xdocs/howto howtovisualagedebug.xml Log: broken links fixed. Revision ChangesPath 1.3 +2 -2 manual/src/xdocs/howto/howtovisualagedebug.xml Index: howtovisualagedebug.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtovisualagedebug.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- howtovisualagedebug.xml 2001/09/02 14:04:28 1.2 +++ howtovisualagedebug.xml 2001/09/05 08:37:55 1.3 @@ -68,9 +68,9 @@ listitem paraAll jBoss source (src subdirectory). /para - paraSource of org.jnp.server (both *.class and *.java files) from ulink url=/doco_files/vaj-jnpserver222.ziphere/ulink. + paraSource of org.jnp.server (both *.class and *.java files) from the ulink url=/doco_files/vaj-jnpserver222.jarvaj-jnpserver222.jar/ulink archive found in the files area on the documentation page on www.jboss.org. /para - paraSource of org.jbossmq.* from ulink url=/doco_files/vaj-jbossmq222.ziphere/ulink./para + paraSource of org.jbossmq.* from the ulink url=/doco_files/vaj-jbossmq222.jarvaj-jbossmq222.jar/ulink archive found in the files area on the documentation page on www.jboss.org./para paraorg.jboss.security.SecurityAssociation source from CVS (version 1.5, which can be found ulink url=http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jboss/src/main/org/jboss/security/SecurityAssociation.java?rev=1.5amp;content-type=text/vnd.viewcvs-markup;here)/ulink/para paraorg.jboss.naming.NamingService from CVS (version 1.9, which can be found ulink url=http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/jboss/jboss/src/main/org/jboss/naming/NamingService.java?rev=1.9amp;content-type=text/x-java;here)/ulink/para ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
I'm assuming that in a JBoss cluster Enterprise Applications are distributed from one node (possibly a Master) to all other nodes (possibly Slaves). I was considering this with respect to the Jetty integration. I'm assuming that a JBoss/Jetty cluster user may wish to deploy some legacy content, seeing as they have a shining new cluster available to them, and some cobwebby old files that they need to make available. By legacy I mean, content such as html, cgi etc. I can either ignore the problem, or as I have chosen to do - consider it (I do so since Jetty is also a decent WebServer and from a Jetty point of view it would be good to continue to support this functionality within a cluster). I assume that distributable unit of choice here for web-content is still a WAR (probably within an EAR - if you wish more control over your context). Thus if I wish to distribute some static HTML files - no problem. I can bundle them up into a WAR and hot deploy them onto one node - and they will be copied everywhere ? With CGI things get a little more difficult. Ideally I would like to bundle up the directory structure into a WAR and deploy it in the same way as the static content. However there are two problems with this. Firstly I would need to specify some mappings for the CGI Servlet - so it knew which files were scripts and what was static and secondly JAR seems to throw away executable bits on files - so unless I build a list of all of these (we're talking Unix now...) before archiving, then have the CGI Servlet reset these in it's init() method, WARs are not going to work for me here. Alternatively we could consider another type of deployable - perhaps a TAR file. So I would drop my legacy.tar into the deploy directory, whence it would be distributed to all nodes' TARDeployers for unpacking A nicer idea might be a WEB-INF/cgi-web.xml which just remembers which files need their executable bit setting at init() time. This could also store other information that might be needed such as external requirements on script interpreters, paths, environments etc.. A little off topic I know... In summary, Is this how RH will distribute Applications ? Can I deploy into any node directly - or only a Master node ? Is there a way to preserve executable bits within JARs - or do I need to workaround ? Thanks for your time folks, Jules Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Architecture Qs for Log4J/JBoss
Hi, We have a java.lang.NoClassDefFoundError: org/apache/log4j/Category in a class that is used by an EJB. This class is in a jar that is in the classpath of JBoss. If I put log4j.jar in JBoss classpath we have an error. Any idea? SAINT-MARTIN Cecile [EMAIL PROTECTED] -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : mercredi 5 septembre 2001 04:13 À : John Cho; [EMAIL PROTECTED] Objet : Re: [JBoss-dev] Architecture Qs for Log4J/JBoss Describe the details of your problem as I have no trouble using log4j in ejbs, servlets, etc. The log4j classes are loaded by the mlet class loader and are available to all other classes. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH Startup time needs work
Windows 2000, P3-900 [Default] JBoss pre-3.0 [RABBIT-HOLE] Started in 0m:18s (includes the 5 sec hypersonic db delay) jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Tuesday, September 04, 2001 9:08 PM To: JBoss Dev Subject: Re: [JBoss-dev] RH Startup time needs work Then I would guess the issue is the class loader. I have seen large differences in performance between custom class loaders on w2k vs linux due to issues with the File class resolving paths very slowly on w2k. The same code starts in 17s on my linux box: [Default] JBoss 3.0.0alpha(DEV) [RABBIT-HOLE] Started in 0m:17s - Original Message - From: marc fleury [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; JBoss Dev [EMAIL PROTECTED] Sent: Tuesday, September 04, 2001 5:54 PM Subject: RE: [JBoss-dev] RH Startup time needs work hmmm... I see 12 on RedHat 7.1 and Athlon 1.4 Ghz, something is not right, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, September 04, 2001 7:50 PM |To: JBoss Dev |Subject: [JBoss-dev] RH Startup time needs work | | |It looks like some performance tuning needs to be done with the new class |loader |and or initialization code as the startup time has gone from 9 |seconds to 65 |seconds: | |... |[Default] JBoss 2.4.0 Started in 0m:9s | |... |[Default] JBoss 3.0.0alpha(DEV) [RABBIT-HOLE] Started in 1m:5s | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH Startup time needs work
|performance between custom class loaders on w2k vs linux due to issues with |the File class resolving paths very slowly on w2k. The same code starts in |17s on my linux box: Hmmm it should not be dramatically slower than the MLet from JMX though so it is fixable on windows. I must admit I don't know about the File class resolving path stuff you mention so if you had more information that would be useful. |[Default] JBoss 3.0.0alpha(DEV) [RABBIT-HOLE] Started in 0m:17s Yes that is more on the order of what I see (and it includes 5 sec of waiting for HSQL) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results
Hi, From: David Jencks [EMAIL PROTECTED] Having these tests back is wonderful but... WHATS GOING ON? the test script appears to be assuming every class whose name begins with Test is a test-- does this mean I have to rewrite my tests to rename the ejbs and mbeans that I happened to name e.g. TestSomethingMBean? Couldn't we only assume classes are tests if they are in a .../test/xxx/test/ directory? Also, there is some kind of security exception from rmi making even less information come back from the server than previously. Anyone know what this is about? (cf eg jmx/test/TestConnectionFactoryLoader) I think the testsuite/test run ant scripts need some work to include/exclude the right stuff - and/or to follow some naming convention - I think Jason mentioned this a few weeks back... Chris _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results
Tests often include utility classes in the same directory so just assuming everything is a test case is not valid. The unit test class naming conventions allow for: Test*.class *Test.class Main.class AllJUnitTests.class - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 7:08 AM Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results Hi, From: David Jencks [EMAIL PROTECTED] Having these tests back is wonderful but... WHATS GOING ON? the test script appears to be assuming every class whose name begins with Test is a test-- does this mean I have to rewrite my tests to rename the ejbs and mbeans that I happened to name e.g. TestSomethingMBean? Couldn't we only assume classes are tests if they are in a .../test/xxx/test/ directory? Also, there is some kind of security exception from rmi making even less information come back from the server than previously. Anyone know what this is about? (cf eg jmx/test/TestConnectionFactoryLoader) I think the testsuite/test run ant scripts need some work to include/exclude the right stuff - and/or to follow some naming convention - I think Jason mentioned this a few weeks back... Chris ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
SAR dir install was [JBoss-dev] RH startup and JBossMQ
|JBossMQ should now work as it did before, at least it does for me. However |I am also in the process of turning the MQ service into a .jsr file, just |because it would be cool to hot deploy JBossMQ. Thanks for these fixes they seem good. ALso try to make sure that we deploy the directory that mq needs. It is the only way that I see the integration of modules done cleanly. Right now the top level directories are confusing in JBoss/Jetty you see jboss and jetty and the ejb stuff etc what we need is the seed directories and then the sar/dir structure. For example make sure that your stuff doesn't touch files everywhere in the hierarchy but that your hierarchy is fully present in a directory node. I think the vision communicated by jason is getting clearer and clearer he was also making the point of creating pellets of java sars with native code in it. This way the octopus can cleanly deploy and install jsr stuff on targets for the duration of work and then undeploy. |I also changed the code to recognise .sar files as well as .jsr files (same |format just different extension). Yes I saw that, good :) David, do me favor, when you modify the classes like you just did, you please 1- add yourself as an author, these are significant changes 2- Put the revisions history in the code for us to track it the cvs is not enough lately thanks marcf | |Cheers, |David. | | -Original Message- | From: David Maplesden [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 05, 2001 10:33 AM | To: JBossDev (E-mail) | Subject: RE: [JBoss-dev] RH startup and JBossMQ | | | OK, I will have a look at this and packaging JBossMQ into a | jsr file to get | it all working (at the moment it is seriously broken, no messages are | restored from backup at all). | | I think though that there are advantages to refactoring | JBossMQ away from | having so many mbeans to letting the statemanager handle more | of the queue | and topic setup. I would like to hear Hirams thoughts on the | matter before | charging into it. | | David | | -Original Message- | From: marc fleury [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 05, 2001 10:32 AM | To: David Maplesden; JBossDev (E-mail) | Subject: RE: [JBoss-dev] RH startup and JBossMQ | | | Rework for the list. | | Basically my take is that making the init/start scope go to | the XML snippet | is not an issue just requires some basic changes to the | ServiceDeployer and | the ServiceController. David take it away. | | marcf | | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On | Behalf Of David | |Maplesden | |Sent: Tuesday, September 04, 2001 5:31 PM | |To: JBossDev (E-mail) | |Subject: RE: [JBoss-dev] RH startup and JBossMQ | | | | | |OK, it seems the situation is much as I thought. | | | |I will try to explain the problem a bit and then propose a | solution. | | | |Basically the persistence manager, when it is started, needs to | |restore from | |its persistent store any messages that were left from the last run | |of the MQ | |service. For it to be able to do this effectively it needs | to know what | |queues there are that are supposed to exist in the system. Hence | |the queues | |that are created at startup need to be registered with the | jms server (and | |hence the persistence manager) before the persistence | manager is started. | |This means that the persistence manager needs to be created | and initialised | |first, then have the various queues and topics initialised | before the PM is | |started. Clearly this means a two step startup process | because of the | |dependencies between the mbeans. | | | |In more general terms the only reason I can see for needing | a two step | |startup process is if such dependencies exist between | mbeans. For example | |if mbean B requires mbean A to be initialised before it is | initialised AND | |mbean A requires mbean B to be initialised before it is started | |then the two | |step init start process is required to correctly start these | two mbeans. As | |in: | | init mbean A | | init mbean B | | start mbean A | | start mbean B | | | |If the only dependency that exists is that mbean B needs | mbean A to be | |started before it is started then a simple one step start | process should be | |enough. | | | |If this is going to be a general problem then we will need | a generic | |mechanism for dealing with this dependency (the Unit | deployment you | |mentioned?). If however the only place it exists is between | the mbeans of | |jbossmq then the answer is that the individual queues, | topics, persistent | |managers etc should not be mbeans. | | | |If you want to do the first then there should be no problem | |bundling MQ as a | |sar or jsr. If we want to do the second we need to change a bit | |of code and | |do away with all the mbeans (QueueManager, TopicManager, |
Re: [JBoss-dev] Architecture Qs for Log4J/JBoss
Classes using log4j need to be in the lib/ext dir rather than the system classpath. If you need the classes to be on the system classpath move the log4j.jar there as well. - Original Message - From: Saint-Martin Cecile [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 5:00 AM Subject: RE: [JBoss-dev] Architecture Qs for Log4J/JBoss Hi, We have a java.lang.NoClassDefFoundError: org/apache/log4j/Category in a class that is used by an EJB. This class is in a jar that is in the classpath of JBoss. If I put log4j.jar in JBoss classpath we have an error. Any idea? SAINT-MARTIN Cecile [EMAIL PROTECTED] -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : mercredi 5 septembre 2001 04:13 À : John Cho; [EMAIL PROTECTED] Objet : Re: [JBoss-dev] Architecture Qs for Log4J/JBoss Describe the details of your problem as I have no trouble using log4j in ejbs, servlets, etc. The log4j classes are loaded by the mlet class loader and are available to all other classes. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: newsite/src/docs/pictures jboss.survey.ear
relax jason, Andreas recently joined JBoss Group full time and will be working with you actually on the administration implementations. This is the survey package for the JBoss download so that we have an idea of who is using us and providing a place for people to give feedback. I agree that pictures is not an idea place though. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Wednesday, September 05, 2001 3:59 AM |To: Andreas Mad Schaefer |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] CVS update: newsite/src/docs/pictures |jboss.survey.ear | | |Where does this come from? | |How does it deploy... does it deploy? | |What is it doing in pictures/? | |=] | |--jason | | |On Wed, 5 Sep 2001, Andreas Mad Schaefer wrote: | | User: schaefera | Date: 01/09/05 00:10:56 | | Modified:src/docs/pictures jboss.survey.ear | Log: | Update version of JBoss Survey | | Revision ChangesPath | 1.2 +326 -257 newsite/src/docs/pictures/jboss.survey.ear | | Binary file | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
Man, you and jason are just on fire... great, great... |Well it turns out it's not too hard to simply turn the MQ service into a |jsr/sar and hot deploy from the deploy directory. However some problems |turn up (of course) when you have other mbeans that rely on the MQ service. |Obviously this is a problem faced by many mbeans, and it has been |dealt with |previously by listing the mbeans in a particular order within the |jboss-service.xml file. Similarly the auto deployer has a feature where |it scans the deployment directories in a particular order to ensure certain |mbeans are deployed before others. | |However if I understand RH correctly the only reason we have |anything listed |in the jboss_service.xml file is to work around these dependencies, if we |came up with a method of specifying the dependencies in the |service.xml file |then virtually everything (except the deployers themselves) could be |deployed by the auto-deployer from the deploy directories. | |So what do people think about something like... | | ?xml version=1.0 encoding=UTF-8? | server | | dependsJBOSS-SYSTEM:service=Naming/depends | dependsJBOSS-SYSTEM:service=AnotherService/depends | | classpath archives=jbossmq.jar/ | | mbean code=org.jboss.mq.server.JBossMQService |name=JBossMQ:service=Server/ | | *snip*snip* | | /server | |And then the deployer would delay the deployment of the mbeans in the xml |file until the mbeans listed in depends tags are deployed as well as |deploying the mbeans in the file in the order listed. This should |take care |of 'fine-grained' and 'course-grained' dependencies. Thanks that is an easy solution. You will create a graph of dependencies in the service controller. It was needed for the longest time. If I remember correctly someone coded that long time ago and you might find a trace of the dependency manager somewhere in the attic. On another note, when we did the CL research with Jung back in December, we exchanged a couple of emails on the topic you are adressing. My gut feeling at the time was that we could possibly intercept a dependency call (on class dependency) (in our precise case in the MBeanClassLoader) and if there is a CNFE then we hold on that dependency in the ServicesLibrary. When that class is deployed the SL notifies the deployer that can restart deployment on the MBean. Advantages: mr clean, automated, no admin intervention, will even feel spooky :) down: complicated to code, tricky concurrency issues, doesn't work for JMX calls (you never reference the *class* of the target). My own vote on my own suggestion at this point is thumbs down for the simple reason that the explicit MBean dependency is simpler for us to code. So go ahead with your idea, XP. It is simpler than ClassLoader dependency graphs that a certain Rickard Oberg was advocating for administrators to build, but it is still MBean dependencies built by administrators when we could do away with it. I don't see a problem with requiring that administrators be aware of what services depend on what services. It seems like a natural task, jason? marcf marcf | |Alternatively we could define dependencies on a per mbean basis rathar than |per unit (a unit as defined by each xml file) but in some cases there |would be just too many dependencies to list conveniently. | |David | | -Original Message- | From: David Maplesden [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 05, 2001 1:49 PM | To: JBossDev (E-mail) | Subject: RE: [JBoss-dev] RH startup and JBossMQ | | | Ok I have just committed some changes to the ServiceDeployer and | ServiceController code. | | Basically the ServiceDeployer now initialises all the mbeans | referred to in | a jboss-service.xml file before starting them. The changes | were fairly | straight-forward and I tested them out with the default | configuration and by | deploying and undeploying additional .jsr files. Everything | seems to work | fine, let me know if anyone has any problems. | | JBossMQ should now work as it did before, at least it does | for me. However | I am also in the process of turning the MQ service into a | .jsr file, just | because it would be cool to hot deploy JBossMQ. | | I also changed the code to recognise .sar files as well as | .jsr files (same | format just different extension). | | Cheers, | David. | | -Original Message- | From: David Maplesden [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 05, 2001 10:33 AM | To: JBossDev (E-mail) | Subject: RE: [JBoss-dev] RH startup and JBossMQ | | | OK, I will have a look at this and packaging JBossMQ into a | jsr file to get | it all working (at the moment it is seriously broken, no | messages are | restored from backup at all). | | I think though that there are advantages to refactoring | JBossMQ away from | having so many mbeans to letting the statemanager handle more | of the queue | and topic
RE: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
|I'm assuming that in a JBoss cluster Enterprise |Applications are distributed from one node (possibly a |Master) to all other nodes (possibly Slaves). | |I was considering this with respect to the Jetty |integration. | |I'm assuming that a JBoss/Jetty cluster user may wish |to deploy some legacy content, seeing as they have a |shining new cluster available to them, and some |cobwebby old files that they need to make available. | |By legacy I mean, content such as html, cgi etc. | |I can either ignore the problem, or as I have chosen |to do - consider it (I do so since Jetty is also a |decent WebServer and from a Jetty point of view it |would be good to continue to support this |functionality within a cluster). | |I assume that distributable unit of choice here for |web-content is still a WAR (probably within an EAR - |if you wish more control over your context). | |Thus if I wish to distribute some static HTML files - |no problem. I can bundle them up into a WAR and hot |deploy them onto one node - and they will be copied |everywhere ? Andreas has started tackling the problem as a JBoss Group employee. His mission is to deploy a service to many targets using the new RH CL stuff . The goal is to take a JDBC sar and mirror install it on 2 machines from http. We are working and learning about it. Installing web wars should not be much more complex. |With CGI things get a little more difficult. Ideally I |would like to bundle up the directory structure into a |WAR and deploy it in the same way as the static |content. However there are two problems with this. |Firstly I would need to specify some mappings for the |CGI Servlet - so it knew which files were scripts and |what was static and secondly JAR seems to throw away |executable bits on files - so unless I build a list of |all of these (we're talking Unix now...) before |archiving, then have the CGI Servlet reset these in |it's init() method, WARs are not going to work for me |here. Jason wants to deploy native stuff to targets, it seems to me that a local deployer could do wonders there. |Is this how RH will distribute Applications ? yes, but first we want to do the services. make sure that works and the war shouldn't be more complex |Can I deploy into any node directly - or only a Master |node ? It will be a logical server as a group of servers. We are also researching the ways to make the grouping easy (jini?) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH Startup time needs work
Scott, please try to track what you see something in obviously broken and it slows down the startup time, it would be great to know what it is. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of James |Cook |Sent: Wednesday, September 05, 2001 8:38 AM |To: jBoss Development |Subject: RE: [JBoss-dev] RH Startup time needs work | | |Windows 2000, P3-900 |[Default] JBoss pre-3.0 [RABBIT-HOLE] Started in 0m:18s |(includes the 5 sec hypersonic db delay) | |jim | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of Scott | M Stark | Sent: Tuesday, September 04, 2001 9:08 PM | To: JBoss Dev | Subject: Re: [JBoss-dev] RH Startup time needs work | | | Then I would guess the issue is the class loader. I have seen large | differences in | performance between custom class loaders on w2k vs linux due to | issues with | the File class resolving paths very slowly on w2k. The same code |starts in | 17s on my linux box: | | [Default] JBoss 3.0.0alpha(DEV) [RABBIT-HOLE] Started in 0m:17s | | - Original Message - | From: marc fleury [EMAIL PROTECTED] | To: Scott M Stark [EMAIL PROTECTED]; JBoss Dev | [EMAIL PROTECTED] | Sent: Tuesday, September 04, 2001 5:54 PM | Subject: RE: [JBoss-dev] RH Startup time needs work | | | hmmm... | | I see 12 on RedHat 7.1 and Athlon 1.4 Ghz, something is not right, | | marcf | | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On | Behalf Of Scott | |M Stark | |Sent: Tuesday, September 04, 2001 7:50 PM | |To: JBoss Dev | |Subject: [JBoss-dev] RH Startup time needs work | | | | | |It looks like some performance tuning needs to be done with | the new class | |loader | |and or initialization code as the startup time has gone from 9 | |seconds to 65 | |seconds: | | | |... | |[Default] JBoss 2.4.0 Started in 0m:9s | | | |... | |[Default] JBoss 3.0.0alpha(DEV) [RABBIT-HOLE] Started in 1m:5s | | | | | |___ | |Jboss-development mailing list | |[EMAIL PROTECTED] | |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
marc fleury wrote: | ?xml version=1.0 encoding=UTF-8? | server | | dependsJBOSS-SYSTEM:service=Naming/depends | dependsJBOSS-SYSTEM:service=AnotherService/depends | | classpath archives=jbossmq.jar/ | | mbean code=org.jboss.mq.server.JBossMQService |name=JBossMQ:service=Server/ | | *snip*snip* | | /server Sometime in a bright future this, and the actual service config stuff, really should be in RDF (http://www.w3.org/RDF/). It would be very very cool as it wouldn't then be XML-dependent, i.e. you could store it in the-whatever-store (e.g. LDAP, e.g. RDBMS). Thanks that is an easy solution. You will create a graph of dependencies in the service controller. It was needed for the longest time. If I remember correctly someone coded that long time ago and you might find a trace of the dependency manager somewhere in the attic. I implemented this in my XS server (google on it to find it :-), and it was one of the things I've been missing in JBoss. Should've been done properly ages ago. My own vote on my own suggestion at this point is thumbs down for the simple reason that the explicit MBean dependency is simpler for us to code. So go ahead with your idea, XP. Yes, explicit is probably better. It is simpler than ClassLoader dependency graphs that a certain Rickard Oberg was advocating ehrm.. wouldn't say advocating, more like mentioned as a possibility. Aaanyway. for administrators to build, but it is still MBean dependencies built by administrators when we could do away with it. I don't see a problem with requiring that administrators be aware of what services depend on what services. It seems like a natural task, jason? I'd like to pop in a thought from the Jini-line of thinking: in Jini you don't specify what services you want, instead you say I want something that looks like this. Of course, if you specify enough you will end up with saying exactly which service you want, but that's not the standard case. The J2EE way, or rather the JNDI way, is to say I want the object named X, so there's no flexibility. You know what you want, and that's that. It's rather uninspired IMnsHO. So, one could adopt the Jini way and let the developer of the MBean, not the administrator of the server, say This MBean depends on the availability of other MBeans looking like this and this. That could be expressed either in code, or in XML. The key point is that this shouldn't really have to be done in the configuration of the service/server, because it involves knowledge that the admin really *shouldn't have to have*. Also, one could argue whether to put this in the MBean itself or in a separate MBean. Inside the MBean would mean that the MBean itself could be put into any other server and still function, whereas in a separate MBean would then require that this extra MBean is also deployed in the server (which may be != JBoss). Actually, one could have the same argument about the configuration persistence. Currently the JBoss server pushes config to the MBean, whereas it is much more portable to let the MBean pull. And I believe the JMX spec actually promotes this way of doing it (look at the PersistentMBean/ModelMBean interface). That said, the actual MBean could still be using get/set methods, it's just that the MBean itself uses some util code to get the config and call these methods by using reflection on itself. The result is a more self-contained MBean that can live in a more core JMX environment. Wouldn't that be just cool. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] How do servlets get EJB objects when servlet is in one container and ejb in another?
Hey all, I am trying to run JBoss on one computer, and Orion on another (soon to be replaced with Jetty). I want to simulate a multi-tier setup so that we can scale on both web and middle tiers. When I deployed ejbs and servlets in same container, all was fine. Never tried using Orion in two separate JVMs to access EJBs in one container from the other container. I got one reply on the forums saying to just look up the EJB name, not the java:comp/env/ejb/Name. My worry is that this would break an application if you have to change every reference to getting EJB's. So how can I get one servlet container to get access to any EJB container (any = one or more because when you scale your load balancer (i assume) would send the request to get an ejb to a server based on load). I'd appreciate any examples, or any links to show how to do this. I tried the jboss.org documentation but it didn't really have this example. For those responsible for the jboss docs, I think this would be a very beneficial topic to include in the tutorial section. A lot of people would be interested in this no doubt as multi-tier is one of the big reasons to move to J2EE, to separate your business logic into its own tier so that you can scale the web tier or the middle tier separately as needed. Thanks guys/gals, appreciate any help.
Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
- Original Message - From: marc fleury [EMAIL PROTECTED] To: Julian Gosnell [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 8:05 AM Subject: RE: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling ! |I'm assuming that in a JBoss cluster Enterprise |Applications are distributed from one node (possibly a |Master) to all other nodes (possibly Slaves). I think to have a master which propagates the actions to the slaves is difficult when it comes to fail-over. It would be nice if the client doesn't know anything about a master but the logical server or view on top of the group of physical servers. There are 3 ways to implement the logical server: 1) the client handles this but then different clients can have different logical views 2) having a separate, stripped-down administration server providing the logical view. When this server goes down the client has to start a new one maybe on another server which could lead to the problem where you want to store the information about the servers participating in the logical view 3) Enable every JBoss server to provide the client with the logical view. Therefore as long as one server is up and running you can get a logical view. Now we can use JINI to have a dynamic discovery of the server joining or leaving the logical view. Have fun - Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jboss 3.0 / DataSource problem
Hi, Running latest JBoss 3.0, I have defined a datasource based on Opta2000 driver for MS SQL. I have added the driver to the list of JDBC driver and the opta JAR to the list of jar in top of jboss-service.xml. I used the new way of configuring the pool, I simply copy/paste the one of DefaultDS and changed the minimum. I got this exception while deploying an entity Bean. [JDBCManagedConnectionFactory-1] Unable to create ManagedConnection: javax.resource.ResourceException: Unable to create DB connection: java.sql.SQLException: No suitable driver at org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createManagedConn ection(JDBCManagedConnectionFactory.java:245) Does this say something to somebody ? Thanks. Vincent. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss 3.0 / DataSource problem
well, you still need to declare the JDBC driver in the JDBC MBean thingy. That is one of the things that we need to change, to have the connector declare what driver he is using as opposed to the kludgy MBean we have right now as a front end to loading the drivers. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Vincent Harcq |Sent: Wednesday, September 05, 2001 1:01 PM |To: Dev JBoss |Subject: [JBoss-dev] Jboss 3.0 / DataSource problem | | |Hi, |Running latest JBoss 3.0, |I have defined a datasource based on Opta2000 driver for MS SQL. |I have added the driver to the list of JDBC driver and the opta JAR to the |list of jar in top of jboss-service.xml. |I used the new way of configuring the pool, I simply copy/paste the one of |DefaultDS and changed the minimum. | |I got this exception while deploying an entity Bean. | |[JDBCManagedConnectionFactory-1] Unable to create ManagedConnection: |javax.resource.ResourceException: Unable to create DB connection: |java.sql.SQLException: No suitable driver |at |org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createMa |nagedConn |ection(JDBCManagedConnectionFactory.java:245) | |Does this say something to somebody ? | |Thanks. |Vincent. | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss 3.0 / DataSource problem
Hi, I have come to this problem before calling for help, I have mbean code=org.jboss.jdbc.JdbcProvider name=JBOSS-SYSTEM:service=JdbcProvider attribute name=Drivers com.inet.tds.TdsDriver, org.hsql.jdbcDriver /attribute /mbean BTW, this was enough and the add of Opta2000.jar in classpath archives=... was also needed. The Pool is created ok. It is at first SQL connection that badaboom. Regards. Vincent. -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoyé : mercredi 5 septembre 2001 19:09 À : [EMAIL PROTECTED]; Dev JBoss Objet : RE: [JBoss-dev] Jboss 3.0 / DataSource problem well, you still need to declare the JDBC driver in the JDBC MBean thingy. That is one of the things that we need to change, to have the connector declare what driver he is using as opposed to the kludgy MBean we have right now as a front end to loading the drivers. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Vincent Harcq |Sent: Wednesday, September 05, 2001 1:01 PM |To: Dev JBoss |Subject: [JBoss-dev] Jboss 3.0 / DataSource problem | | |Hi, |Running latest JBoss 3.0, |I have defined a datasource based on Opta2000 driver for MS SQL. |I have added the driver to the list of JDBC driver and the opta JAR to the |list of jar in top of jboss-service.xml. |I used the new way of configuring the pool, I simply copy/paste the one of |DefaultDS and changed the minimum. | |I got this exception while deploying an entity Bean. | |[JDBCManagedConnectionFactory-1] Unable to create ManagedConnection: |javax.resource.ResourceException: Unable to create DB connection: |java.sql.SQLException: No suitable driver |at |org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createMa |nagedConn |ection(JDBCManagedConnectionFactory.java:245) | |Does this say something to somebody ? | |Thanks. |Vincent. | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss 3.0 / DataSource problem
|BTW, this was enough and the add of Opta2000.jar in classpath archives=... |was also needed. no this is only needed if you run http based which you are not. Dropping the jar in the lib/ext is enough. |The Pool is created ok. does this means it finds the connection... |It is at first SQL connection that badaboom. This works with the hsql driver... can you narrow the problem down a bit? marcf | |Regards. |Vincent. | | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoyé : mercredi 5 septembre 2001 19:09 | À : [EMAIL PROTECTED]; Dev JBoss | Objet : RE: [JBoss-dev] Jboss 3.0 / DataSource problem | | | well, | | you still need to declare the JDBC driver in the JDBC MBean thingy. | | That is one of the things that we need to change, to have the connector | declare what driver he is using as opposed to the kludgy MBean we | have right | now as a front end to loading the drivers. | | marcf | | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On Behalf Of | |Vincent Harcq | |Sent: Wednesday, September 05, 2001 1:01 PM | |To: Dev JBoss | |Subject: [JBoss-dev] Jboss 3.0 / DataSource problem | | | | | |Hi, | |Running latest JBoss 3.0, | |I have defined a datasource based on Opta2000 driver for MS SQL. | |I have added the driver to the list of JDBC driver and the opta | JAR to the | |list of jar in top of jboss-service.xml. | |I used the new way of configuring the pool, I simply copy/paste | the one of | |DefaultDS and changed the minimum. | | | |I got this exception while deploying an entity Bean. | | | |[JDBCManagedConnectionFactory-1] Unable to create ManagedConnection: | |javax.resource.ResourceException: Unable to create DB connection: | |java.sql.SQLException: No suitable driver | |at | |org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createMa | |nagedConn | |ection(JDBCManagedConnectionFactory.java:245) | | | |Does this say something to somebody ? | | | |Thanks. | |Vincent. | | | | | |___ | |Jboss-development mailing list | |[EMAIL PROTECTED] | |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458675 ] setByteProperty() not working
Bugs item #458675, was opened at 2001-09-05 04:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=458675group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Aleksey Studnev (studnev) Assigned to: Nobody/Anonymous (nobody) Summary: setByteProperty() not working Initial Comment: Calling setByteProperty(String,byte) of Message returns exception NoSuchMethodError Changing to setIntProperty(String,int) works fine -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=458675group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: newsite/src/docs/pictures jboss.survey.ear
relax jason, I am relaxed. I realize that the bombardment of questions might come across as a little harsh, so I added a happy drunk face to soften things up. I would really like to have this integrated with the jboss-website build system, so it is easier to manage. Andreas recently joined JBoss Group full time and will be working with you actually on the administration implementations. Excellent. This is the survey package for the JBoss download so that we have an idea of who is using us and providing a place for people to give feedback. When I was putting together jboss-website, I searched through the entire site and did not find any references to this, perhaps I missed something. I agree that pictures is not an idea place though. Definitely not. If this is something meant to run inside of jboss.org, then the sources used to build it should be checked and the .ear should be generated by the jboss-website build system. That is all I was trying to get at. My apologies if this came across as anything other than that. --jason marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Wednesday, September 05, 2001 3:59 AM |To: Andreas Mad Schaefer |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] CVS update: newsite/src/docs/pictures |jboss.survey.ear | | |Where does this come from? | |How does it deploy... does it deploy? | |What is it doing in pictures/? | |=] | |--jason | | |On Wed, 5 Sep 2001, Andreas Mad Schaefer wrote: | | User: schaefera | Date: 01/09/05 00:10:56 | | Modified:src/docs/pictures jboss.survey.ear | Log: | Update version of JBoss Survey | | Revision ChangesPath | 1.2 +326 -257 newsite/src/docs/pictures/jboss.survey.ear | |Binary file | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool/connector/jdbc JDBCManagedConnectionFactory.java
User: kimptoc
Date: 01/09/05 12:30:24
Modified:src/main/org/jboss/pool/connector/jdbc
JDBCManagedConnectionFactory.java
Log:
add some more info to the ManagedConnection error
Revision ChangesPath
1.4 +2 -2
jbosspool/src/main/org/jboss/pool/connector/jdbc/JDBCManagedConnectionFactory.java
Index: JDBCManagedConnectionFactory.java
===
RCS file:
/cvsroot/jboss/jbosspool/src/main/org/jboss/pool/connector/jdbc/JDBCManagedConnectionFactory.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JDBCManagedConnectionFactory.java 2001/08/19 04:55:31 1.3
+++ JDBCManagedConnectionFactory.java 2001/09/05 19:30:24 1.4
@@ -82,7 +82,7 @@
* @author Aaron Mulder [EMAIL PROTECTED]
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
* @createdAugust 18, 2001
- * @version$Revision: 1.3 $
+ * @version$Revision: 1.4 $
*/
public class JDBCManagedConnectionFactory implements ManagedConnectionFactory {
private String driver;
@@ -242,7 +242,7 @@
ManagedConnection mc = new JDBCManagedConnection( con, user, url );
return mc;
} catch ( SQLException e ) {
- throw new ResourceException( Unable to create DB connection: + e );
+ throw new ResourceException( Unable to create DB connection (url=+url+,
user=+user+: + e );
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results
Can we rename, so that all test end with *Test.class, or *TestCase.class? I was looking into some of the errors yesterday, but did not really have any energy to do anything about it. I saw a few interfaces were thought to be tests and some odd naming problems. I also didn't see all of the tests on the output page again. --jason On Wed, 5 Sep 2001, Scott M Stark wrote: Tests often include utility classes in the same directory so just assuming everything is a test case is not valid. The unit test class naming conventions allow for: Test*.class *Test.class Main.class AllJUnitTests.class - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 7:08 AM Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results Hi, From: David Jencks [EMAIL PROTECTED] Having these tests back is wonderful but... WHATS GOING ON? the test script appears to be assuming every class whose name begins with Test is a test-- does this mean I have to rewrite my tests to rename the ejbs and mbeans that I happened to name e.g. TestSomethingMBean? Couldn't we only assume classes are tests if they are in a .../test/xxx/test/ directory? Also, there is some kind of security exception from rmi making even less information come back from the server than previously. Anyone know what this is about? (cf eg jmx/test/TestConnectionFactoryLoader) I think the testsuite/test run ant scripts need some work to include/exclude the right stuff - and/or to follow some naming convention - I think Jason mentioned this a few weeks back... Chris ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
This would be cool, very cool in fact, but a little ambitious for my available time frame right now. I think I will go ahead with the simple dependency checking I outlined previously. Unless there is someone who feels like taking on your challenge... David -Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 3:08 AM To: [EMAIL PROTECTED] Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ) marc fleury wrote: | ?xml version=1.0 encoding=UTF-8? | server | | dependsJBOSS-SYSTEM:service=Naming/depends | dependsJBOSS-SYSTEM:service=AnotherService/depends | | classpath archives=jbossmq.jar/ | | mbean code=org.jboss.mq.server.JBossMQService |name=JBossMQ:service=Server/ | | *snip*snip* | | /server Sometime in a bright future this, and the actual service config stuff, really should be in RDF (http://www.w3.org/RDF/). It would be very very cool as it wouldn't then be XML-dependent, i.e. you could store it in the-whatever-store (e.g. LDAP, e.g. RDBMS). Thanks that is an easy solution. You will create a graph of dependencies in the service controller. It was needed for the longest time. If I remember correctly someone coded that long time ago and you might find a trace of the dependency manager somewhere in the attic. I implemented this in my XS server (google on it to find it :-), and it was one of the things I've been missing in JBoss. Should've been done properly ages ago. My own vote on my own suggestion at this point is thumbs down for the simple reason that the explicit MBean dependency is simpler for us to code. So go ahead with your idea, XP. Yes, explicit is probably better. It is simpler than ClassLoader dependency graphs that a certain Rickard Oberg was advocating ehrm.. wouldn't say advocating, more like mentioned as a possibility. Aaanyway. for administrators to build, but it is still MBean dependencies built by administrators when we could do away with it. I don't see a problem with requiring that administrators be aware of what services depend on what services. It seems like a natural task, jason? I'd like to pop in a thought from the Jini-line of thinking: in Jini you don't specify what services you want, instead you say I want something that looks like this. Of course, if you specify enough you will end up with saying exactly which service you want, but that's not the standard case. The J2EE way, or rather the JNDI way, is to say I want the object named X, so there's no flexibility. You know what you want, and that's that. It's rather uninspired IMnsHO. So, one could adopt the Jini way and let the developer of the MBean, not the administrator of the server, say This MBean depends on the availability of other MBeans looking like this and this. That could be expressed either in code, or in XML. The key point is that this shouldn't really have to be done in the configuration of the service/server, because it involves knowledge that the admin really *shouldn't have to have*. Also, one could argue whether to put this in the MBean itself or in a separate MBean. Inside the MBean would mean that the MBean itself could be put into any other server and still function, whereas in a separate MBean would then require that this extra MBean is also deployed in the server (which may be != JBoss). Actually, one could have the same argument about the configuration persistence. Currently the JBoss server pushes config to the MBean, whereas it is much more portable to let the MBean pull. And I believe the JMX spec actually promotes this way of doing it (look at the PersistentMBean/ModelMBean interface). That said, the actual MBean could still be using get/set methods, it's just that the MBean itself uses some util code to get the config and call these methods by using reflection on itself. The result is a more self-contained MBean that can live in a more core JMX environment. Wouldn't that be just cool. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
It will be a logical server as a group of servers. We are also researching the ways to make the grouping easy (jini?) I would really like to hear more about how jini could make jboss a truly amazing and robust distributed operating system. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/pictures jboss.survey.ear jboss.survey.zip
User: schaefera Date: 01/09/05 14:00:11 Removed: src/docs/pictures jboss.survey.ear jboss.survey.zip Log: Files shouldn't be here. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
|I'm assuming that in a JBoss cluster Enterprise |Applications are distributed from one node (possibly a |Master) to all other nodes (possibly Slaves). I think to have a master which propagates the actions to the slaves is difficult when it comes to fail-over. It would be nice if the client doesn't know anything about a master but the logical server or view on top of the group of physical servers. I don't know if this master/slave stuff spawned from something I said, if so I want to clearify what I was talking about. If not, well then, here it is anyways =) When I was talking about master/slave, the master would trully be a dumb server, which had the sole responsiblity for starting up slave nodes, cycling them when they wedged, responing them when the jvm crashed and so on. The slave node in this view would be configured to run your application services. In a simple case, there would only be one slave for a master. The master would simply startup, then spawn the slave, watch for it to exit (as well as listen for lifecycle JMX events) and not really do more than that. By adding this small piece of architecture to the system, we can write applications that can replicate there environment automatically for fail over, provide a sandbox environment for applications that might run native libraries or be prone to sucking up memory with out endangering other critical services that must be runnining on the same machine. I think this will be important when it comes to really distributed uses of jboss in a mission critial application. Now that the configuration of the server can be loaded from a URL, the task of startup up new nodes is simply, looking up the URL to use. On boot, the task is simply looking up the list of URLs to load, then starting a JBoss slave node for each. To make somthing like this work, you need a configuration server, which is simply a JBoss node which is booted off of a file:// url, runs a web server and has some .jsp's which server up configurations to other nodes. A master node running on each machine, probably started up vi /etc/init.d/ or the equivilent on other operating systems. It is also a simple JBoss node, which pulls its config from http://configserver/master/ (perhaps with hostname, os and other params attached so the .jsp under master can dish out the correct config. The slaves looks mostly the same, the master looks up the url, which is probably http://configserver/slave/ (with the same os, arch, other fluff). If jini was used, then the act of finding the configserver could be more dynamic too. Doing something like this should be fairly simply too, the only hard bit is forking the master node and watching slave children. Java has some primitives to do this, but it could be abstracted out to an interface to allow native impls, which are more effective to be used in its place where available. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBoss MQ)
Adding some form of dependency declaration will help improvde debugging, as a service (or rather the service controller) could throw an exception with the exact service name which is missing, instead of throwing other meaning less exceptions. Not that I really know that it does throw such exceptions, just pointing out that dependencies would help minimize the learning curve in some ways. I understand that it could also be confusing, but if it is left to a minimal design, simple in nature, then it should positivly augment the boot process rather than complicate it. --jason On Wed, 5 Sep 2001, David Maplesden wrote: Well it turns out it's not too hard to simply turn the MQ service into a jsr/sar and hot deploy from the deploy directory. However some problems turn up (of course) when you have other mbeans that rely on the MQ service. Obviously this is a problem faced by many mbeans, and it has been dealt with previously by listing the mbeans in a particular order within the jboss-service.xml file. Similarly the auto deployer has a feature where it scans the deployment directories in a particular order to ensure certain mbeans are deployed before others. However if I understand RH correctly the only reason we have anything listed in the jboss_service.xml file is to work around these dependencies, if we came up with a method of specifying the dependencies in the service.xml file then virtually everything (except the deployers themselves) could be deployed by the auto-deployer from the deploy directories. So what do people think about something like... ?xml version=1.0 encoding=UTF-8? server dependsJBOSS-SYSTEM:service=Naming/depends dependsJBOSS-SYSTEM:service=AnotherService/depends classpath archives=jbossmq.jar/ mbean code=org.jboss.mq.server.JBossMQService name=JBossMQ:service=Server/ *snip*snip* /server And then the deployer would delay the deployment of the mbeans in the xml file until the mbeans listed in depends tags are deployed as well as deploying the mbeans in the file in the order listed. This should take care of 'fine-grained' and 'course-grained' dependencies. Alternatively we could define dependencies on a per mbean basis rathar than per unit (a unit as defined by each xml file) but in some cases there would be just too many dependencies to list conveniently. David -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 1:49 PM To: JBossDev (E-mail) Subject: RE: [JBoss-dev] RH startup and JBossMQ Ok I have just committed some changes to the ServiceDeployer and ServiceController code. Basically the ServiceDeployer now initialises all the mbeans referred to in a jboss-service.xml file before starting them. The changes were fairly straight-forward and I tested them out with the default configuration and by deploying and undeploying additional .jsr files. Everything seems to work fine, let me know if anyone has any problems. JBossMQ should now work as it did before, at least it does for me. However I am also in the process of turning the MQ service into a .jsr file, just because it would be cool to hot deploy JBossMQ. I also changed the code to recognise .sar files as well as .jsr files (same format just different extension). Cheers, David. -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 10:33 AM To: JBossDev (E-mail) Subject: RE: [JBoss-dev] RH startup and JBossMQ OK, I will have a look at this and packaging JBossMQ into a jsr file to get it all working (at the moment it is seriously broken, no messages are restored from backup at all). I think though that there are advantages to refactoring JBossMQ away from having so many mbeans to letting the statemanager handle more of the queue and topic setup. I would like to hear Hirams thoughts on the matter before charging into it. David -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 10:32 AM To: David Maplesden; JBossDev (E-mail) Subject: RE: [JBoss-dev] RH startup and JBossMQ Rework for the list. Basically my take is that making the init/start scope go to the XML snippet is not an issue just requires some basic changes to the ServiceDeployer and the ServiceController. David take it away. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Maplesden |Sent: Tuesday, September 04, 2001 5:31 PM |To: JBossDev (E-mail) |Subject: RE: [JBoss-dev] RH startup and JBossMQ | | |OK, it seems the situation is much as I thought. | |I will try to explain the
Re: [JBoss-dev] Jboss 3.0 / DataSource problem
One problem that causes this is escaped : ie \: in the jdbc url. right now the example .xml has jdbc\:HypersonicDatabase\:hsql\: Try jdbc:HypersonicDatabase:hsql:... marc's new ServiceDeployer removes all newlines from xml which messes up the property file format reading used in ConnectionFactoryLoader. My quick fix for ConnectionFactoryLoader didn't account for escaped :. Not sure how it got through my tests... I think I'll put the newlines back into the xml reader. david jencks On 2001.09.05 13:23:56 -0400 Vincent Harcq wrote: Hi, I have come to this problem before calling for help, I have mbean code=org.jboss.jdbc.JdbcProvider name=JBOSS-SYSTEM:service=JdbcProvider attribute name=Drivers com.inet.tds.TdsDriver, org.hsql.jdbcDriver /attribute /mbean BTW, this was enough and the add of Opta2000.jar in classpath archives=... was also needed. The Pool is created ok. It is at first SQL connection that badaboom. Regards. Vincent. -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoyé : mercredi 5 septembre 2001 19:09 À : [EMAIL PROTECTED]; Dev JBoss Objet : RE: [JBoss-dev] Jboss 3.0 / DataSource problem well, you still need to declare the JDBC driver in the JDBC MBean thingy. That is one of the things that we need to change, to have the connector declare what driver he is using as opposed to the kludgy MBean we have right now as a front end to loading the drivers. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Vincent Harcq |Sent: Wednesday, September 05, 2001 1:01 PM |To: Dev JBoss |Subject: [JBoss-dev] Jboss 3.0 / DataSource problem | | |Hi, |Running latest JBoss 3.0, |I have defined a datasource based on Opta2000 driver for MS SQL. |I have added the driver to the list of JDBC driver and the opta JAR to the |list of jar in top of jboss-service.xml. |I used the new way of configuring the pool, I simply copy/paste the one of |DefaultDS and changed the minimum. | |I got this exception while deploying an entity Bean. | |[JDBCManagedConnectionFactory-1] Unable to create ManagedConnection: |javax.resource.ResourceException: Unable to create DB connection: |java.sql.SQLException: No suitable driver |at |org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createMa |nagedConn |ection(JDBCManagedConnectionFactory.java:245) | |Does this say something to somebody ? | |Thanks. |Vincent. | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Missing JBoss_x_x tags?
I can't seem to cvs co -r JBoss_x_x anymore. I can't get source code tagged back to 2.2.2 or 2.4.0 ? Or am I missing something? I've browsed the cvs source at sourceforge.net, and the tags seem to have disappeared. ? --SIG A HREF=http://www.focalpoint.com/;Home Page/A education is what's left after what is learned is forgotten. -- b f skinner Luigi P. Bai Focal Point Software, Inc. [EMAIL PROTECTED] 3701 Kirby Drive, Suite 512 turning data into information Houston, TX 77098 (713) 215-1600 x 33# ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
Is explict mbean-mbean dependencies really a good idea and/or necessary? We already have, via the classpath element, sar-sar dependencies. Is there a realistic case where having finer grained dependencies is appropriate? Obviously it's possible, is it desirable? Right now there are 2 levels of deployment ordering: 1. in the classpath element, the sars a given sar depends on are loaded (if not already present) in the order listed 2. Within the sar, the mbeans are created in the order listed. What else is needed? Why? david jencks On 2001.09.05 10:47:41 -0400 marc fleury wrote: Man, you and jason are just on fire... great, great... |Well it turns out it's not too hard to simply turn the MQ service into a |jsr/sar and hot deploy from the deploy directory. However some problems |turn up (of course) when you have other mbeans that rely on the MQ service. |Obviously this is a problem faced by many mbeans, and it has been |dealt with |previously by listing the mbeans in a particular order within the |jboss-service.xml file. Similarly the auto deployer has a feature where |it scans the deployment directories in a particular order to ensure certain |mbeans are deployed before others. | |However if I understand RH correctly the only reason we have |anything listed |in the jboss_service.xml file is to work around these dependencies, if we |came up with a method of specifying the dependencies in the |service.xml file |then virtually everything (except the deployers themselves) could be |deployed by the auto-deployer from the deploy directories. | |So what do people think about something like... | | ?xml version=1.0 encoding=UTF-8? | server | | dependsJBOSS-SYSTEM:service=Naming/depends | dependsJBOSS-SYSTEM:service=AnotherService/depends | | classpath archives=jbossmq.jar/ | | mbean code=org.jboss.mq.server.JBossMQService | name=JBossMQ:service=Server/ | | *snip*snip* | | /server | |And then the deployer would delay the deployment of the mbeans in the xml |file until the mbeans listed in depends tags are deployed as well as |deploying the mbeans in the file in the order listed. This should |take care |of 'fine-grained' and 'course-grained' dependencies. Thanks that is an easy solution. You will create a graph of dependencies in the service controller. It was needed for the longest time. If I remember correctly someone coded that long time ago and you might find a trace of the dependency manager somewhere in the attic. On another note, when we did the CL research with Jung back in December, we exchanged a couple of emails on the topic you are adressing. My gut feeling at the time was that we could possibly intercept a dependency call (on class dependency) (in our precise case in the MBeanClassLoader) and if there is a CNFE then we hold on that dependency in the ServicesLibrary. When that class is deployed the SL notifies the deployer that can restart deployment on the MBean. Advantages: mr clean, automated, no admin intervention, will even feel spooky :) down: complicated to code, tricky concurrency issues, doesn't work for JMX calls (you never reference the *class* of the target). My own vote on my own suggestion at this point is thumbs down for the simple reason that the explicit MBean dependency is simpler for us to code. So go ahead with your idea, XP. It is simpler than ClassLoader dependency graphs that a certain Rickard Oberg was advocating for administrators to build, but it is still MBean dependencies built by administrators when we could do away with it. I don't see a problem with requiring that administrators be aware of what services depend on what services. It seems like a natural task, jason? marcf marcf | |Alternatively we could define dependencies on a per mbean basis rathar than |per unit (a unit as defined by each xml file) but in some cases there |would be just too many dependencies to list conveniently. | |David | | -Original Message- | From: David Maplesden [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 05, 2001 1:49 PM | To: JBossDev (E-mail) | Subject: RE: [JBoss-dev] RH startup and JBossMQ | | | Ok I have just committed some changes to the ServiceDeployer and | ServiceController code. | | Basically the ServiceDeployer now initialises all the mbeans | referred to in | a jboss-service.xml file before starting them. The changes | were fairly | straight-forward and I tested them out with the default | configuration and by | deploying and undeploying additional .jsr files. Everything | seems to work | fine, let me know if anyone has any problems. | | JBossMQ should now work as it did before, at least it does | for me. However | I am also in the process of turning the MQ service into a | .jsr file, just | because it would be cool to hot deploy JBossMQ. | | I also changed the
RE: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBoss MQ)
OK just so everyone is clear (now that I have had some time to think about it) what I am proposing to do is as follows: In the jboss-service.xml (or equivalent xml snippet file) it will be possible to have depends tags dependsJBOSS-SYSTEM:service=Naming/depends that name an mbean or mbeans that must be deployed before the mbeans in the file itself can be deployed. The ServiceController will take notice of these tags and build a dependency list for the file. It will then delay the deployment of the file until all the mbeans on the list are deployed. This is to allow several files with interdependencies to be in the auto-deploy directory at the same time and have them deployed correctly. I could add a timeout to the waiting for the dependencies to resolved so that an exception is raised if the deployment seems to be halted indefinately. The mbeans listed within a single file will still be deployed in the order they are listed so that a large number of dependencies can be resolved by listing the mbeans in the same file. This mechanism though will allow us to specify services in separate jsr/sar's when it is useful to do so. This should be fairly simple to implement and relatively effective for our needs. I am not proposing any support for undeployment dependencies (automatically undeploying mbeans when mbeans they rely on are undeployed). The problem is quite a bit more complex. Any comments? David -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 9:17 AM To: David Maplesden Cc: JBossDev (E-mail) Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBoss MQ) Adding some form of dependency declaration will help improvde debugging, as a service (or rather the service controller) could throw an exception with the exact service name which is missing, instead of throwing other meaning less exceptions. Not that I really know that it does throw such exceptions, just pointing out that dependencies would help minimize the learning curve in some ways. I understand that it could also be confusing, but if it is left to a minimal design, simple in nature, then it should positivly augment the boot process rather than complicate it. --jason On Wed, 5 Sep 2001, David Maplesden wrote: Well it turns out it's not too hard to simply turn the MQ service into a jsr/sar and hot deploy from the deploy directory. However some problems turn up (of course) when you have other mbeans that rely on the MQ service. Obviously this is a problem faced by many mbeans, and it has been dealt with previously by listing the mbeans in a particular order within the jboss-service.xml file. Similarly the auto deployer has a feature where it scans the deployment directories in a particular order to ensure certain mbeans are deployed before others. However if I understand RH correctly the only reason we have anything listed in the jboss_service.xml file is to work around these dependencies, if we came up with a method of specifying the dependencies in the service.xml file then virtually everything (except the deployers themselves) could be deployed by the auto-deployer from the deploy directories. So what do people think about something like... ?xml version=1.0 encoding=UTF-8? server dependsJBOSS-SYSTEM:service=Naming/depends dependsJBOSS-SYSTEM:service=AnotherService/depends classpath archives=jbossmq.jar/ mbean code=org.jboss.mq.server.JBossMQService name=JBossMQ:service=Server/ *snip*snip* /server And then the deployer would delay the deployment of the mbeans in the xml file until the mbeans listed in depends tags are deployed as well as deploying the mbeans in the file in the order listed. This should take care of 'fine-grained' and 'course-grained' dependencies. Alternatively we could define dependencies on a per mbean basis rathar than per unit (a unit as defined by each xml file) but in some cases there would be just too many dependencies to list conveniently. David -Original Message- From: David Maplesden [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 1:49 PM To: JBossDev (E-mail) Subject: RE: [JBoss-dev] RH startup and JBossMQ Ok I have just committed some changes to the ServiceDeployer and ServiceController code. Basically the ServiceDeployer now initialises all the mbeans referred to in a jboss-service.xml file before starting them. The changes were fairly straight-forward and I tested them out with the default configuration and by deploying and undeploying additional .jsr files. Everything seems to work fine, let me know if anyone has any problems. JBossMQ should now work as it did before, at least it does for me. However I am also
[JBoss-dev] CVS update: manual/src/examples/build build.xml
User: vharcq
Date: 01/09/05 14:58:01
Modified:src/examples/build build.xml
Log:
Bug 458826, 457149
Chapter JDBC examples did not work.
Revision ChangesPath
1.14 +267 -261 manual/src/examples/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/manual/src/examples/build/build.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- build.xml 2001/08/15 17:25:08 1.13
+++ build.xml 2001/09/05 21:58:01 1.14
@@ -1,261 +1,267 @@
-?xml version=1.0 encoding=UTF-8 ?
-!--
- Ant build file for the documentation tutorial code
- Writer of a chapter with an example have to include a foroward
- to their build file. This latest build file suppose arguments
- sets here :
- src.dir : Directory where the source are : manual\src\examples
- build.dir : Base directory where to store generated files
(class/ejb/war/...)
- classpath : Classpath used to make any compilation (set up here by
verifing
- which version of JBoss is used.
-
- --
-
-project name=CMP default=main basedir=../
-
-property name=env environment=env /
-!-- Override with your JBoss server dist location if the JBOSS_DIST env var is
not set --
-property name=jboss.dist value=${env.JBOSS_DIST}/
-!-- Override with your web server servlet jar location. The default assumes
that
- JBOSS_DIST points to a JBoss/Tomcat bundle distribution
- --
-property name=servlet.jar
value=${env.JBOSS_DIST}}/../tomcat/lib/servlet.jar/
-property name=src.dir value=${basedir}/
-property name=src.resources value=${basedir}/resources/
-property name=build.dir value=${basedir}/build-examples/
-property name=dist.dir value=${basedir}/../../dist-examples/
-
-path id=base.path_22
-pathelement location=${jboss.dist}/client/ejb.jar/
-pathelement location=${jboss.dist}/client/jaas.jar/
-pathelement location=${jboss.dist}/client/jbosssx-client.jar/
-pathelement location=${jboss.dist}/client/jboss-client.jar/
-pathelement location=${jboss.dist}/client/jnp-client.jar/
-pathelement location=${servlet.jar}/
-/path
-path id=base.path_23
-pathelement location=${jboss.dist}/client/jboss-j2ee.jar/
-pathelement location=${jboss.dist}/client/jaas.jar/
-pathelement location=${jboss.dist}/client/jbosssx-client.jar/
-pathelement location=${jboss.dist}/client/jboss-client.jar/
-pathelement location=${jboss.dist}/client/jnp-client.jar/
-pathelement location=${servlet.jar}/
-/path
-
-target name=validate
-available property=classpath_id value=base.path_22
file=${jboss.dist}/client/ejb.jar /
-available property=classpath_id value=base.path_23
file=${jboss.dist}/client/jboss-j2ee.jar /
-/target
-
-target name=fail_if_not_valid unless=classpath_id
-fail message=jboss.dist=${jboss.dist} is not a valid JBoss dist
directory/
-/target
-
-target name=init depends=validate,fail_if_not_valid
-property name=classpath refid=${classpath_id} /
-echo message=Using JBoss directory=${jboss.dist} /
-echo message=Using base classpath=${classpath} /
-echo message=Using Source directory=${src.dir} /
-echo message=Using Build directory=${build.dir} /
-/target
-
-!-- Clean build and dist --
-target name=clean depends=init
- delete dir=${build.dir}/
- delete dir=${dist.dir}/
-/target
-
- !-- No default Target --
-target name=main depends=init
- echo message=Specify which target you want to run. Example: build
cmp-cd-list /
-/target
-
- !-- Target to create files to store on the Web site --
-
-target name=dist depends=clean
- mkdir dir=${dist.dir}/
- !-- Bundle all the sources and build script in one file --
- zip zipfile=${dist.dir}/documentation-example.zip basedir=${src.dir}/../
- includes=examples/** /
- tar tarfile=${dist.dir}/documentation-example.tar basedir=${src.dir}/../
- includes=examples/** /
- gzip src=${dist.dir}/documentation-example.tar
zipfile=${dist.dir}/documentation-example.tar.gz /
- !-- Add Chapter specific files here
- antcall target=cmp-cd-dist /
- --
-/target
-
-!--
*** --
-!-- Chapter 1 - First Steps --
-target name=intro-interest-compile depends=init
-ant antfile=org/jboss/docs/interest/build.xml target=compile /
-/target
-
-target name=intro-interest-jar depends=init
-ant
RE: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
I just feel (though I am willing to be out voted) that specifying the mbeans you are dependent on is more portable than specifying the sar. There might be different versions of the mbean service you want that could be started from different places, you don't really care how or where the mbean comes from, just that it exists before you attempt to deploy this file (sar or xml snippet). -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 9:52 AM To: jboss-dev Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ) Is explict mbean-mbean dependencies really a good idea and/or necessary? We already have, via the classpath element, sar-sar dependencies. Is there a realistic case where having finer grained dependencies is appropriate? Obviously it's possible, is it desirable? Right now there are 2 levels of deployment ordering: 1. in the classpath element, the sars a given sar depends on are loaded (if not already present) in the order listed 2. Within the sar, the mbeans are created in the order listed. What else is needed? Why? david jencks On 2001.09.05 10:47:41 -0400 marc fleury wrote: Man, you and jason are just on fire... great, great... |Well it turns out it's not too hard to simply turn the MQ service into a |jsr/sar and hot deploy from the deploy directory. However some problems |turn up (of course) when you have other mbeans that rely on the MQ service. |Obviously this is a problem faced by many mbeans, and it has been |dealt with |previously by listing the mbeans in a particular order within the |jboss-service.xml file. Similarly the auto deployer has a feature where |it scans the deployment directories in a particular order to ensure certain |mbeans are deployed before others. | |However if I understand RH correctly the only reason we have |anything listed |in the jboss_service.xml file is to work around these dependencies, if we |came up with a method of specifying the dependencies in the |service.xml file |then virtually everything (except the deployers themselves) could be |deployed by the auto-deployer from the deploy directories. | |So what do people think about something like... | | ?xml version=1.0 encoding=UTF-8? | server | | dependsJBOSS-SYSTEM:service=Naming/depends | dependsJBOSS-SYSTEM:service=AnotherService/depends | | classpath archives=jbossmq.jar/ | | mbean code=org.jboss.mq.server.JBossMQService |name=JBossMQ:service=Server/ | | *snip*snip* | | /server | |And then the deployer would delay the deployment of the mbeans in the xml |file until the mbeans listed in depends tags are deployed as well as |deploying the mbeans in the file in the order listed. This should |take care |of 'fine-grained' and 'course-grained' dependencies. Thanks that is an easy solution. You will create a graph of dependencies in the service controller. It was needed for the longest time. If I remember correctly someone coded that long time ago and you might find a trace of the dependency manager somewhere in the attic. On another note, when we did the CL research with Jung back in December, we exchanged a couple of emails on the topic you are adressing. My gut feeling at the time was that we could possibly intercept a dependency call (on class dependency) (in our precise case in the MBeanClassLoader) and if there is a CNFE then we hold on that dependency in the ServicesLibrary. When that class is deployed the SL notifies the deployer that can restart deployment on the MBean. Advantages: mr clean, automated, no admin intervention, will even feel spooky :) down: complicated to code, tricky concurrency issues, doesn't work for JMX calls (you never reference the *class* of the target). My own vote on my own suggestion at this point is thumbs down for the simple reason that the explicit MBean dependency is simpler for us to code. So go ahead with your idea, XP. It is simpler than ClassLoader dependency graphs that a certain Rickard Oberg was advocating for administrators to build, but it is still MBean dependencies built by administrators when we could do away with it. I don't see a problem with requiring that administrators be aware of what services depend on what services. It seems like a natural task, jason? marcf marcf | |Alternatively we could define dependencies on a per mbean basis rathar than |per unit (a unit as defined by each xml file) but in some cases there |would be just too many dependencies to list conveniently. | |David | | -Original Message- | From: David Maplesden [mailto:[EMAIL PROTECTED]] | Sent: Wednesday, September 05, 2001 1:49 PM | To: JBossDev
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins BMPPersistenceManager.java
User: vharcq
Date: 01/09/05 15:02:51
Modified:src/main/org/jboss/ejb/plugins BMPPersistenceManager.java
Log:
Bug 441821
Better messages when methods defined in Home interface are not implemented
Revision ChangesPath
1.31 +31 -4 jboss/src/main/org/jboss/ejb/plugins/BMPPersistenceManager.java
Index: BMPPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/BMPPersistenceManager.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- BMPPersistenceManager.java2001/09/01 19:50:30 1.30
+++ BMPPersistenceManager.java2001/09/05 22:02:51 1.31
@@ -31,6 +31,7 @@
import org.jboss.management.j2ee.CountStatistic;
import org.jboss.management.j2ee.TimeStatistic;
+import org.apache.log4j.Category;
/**
* description
@@ -39,7 +40,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
-* @version $Revision: 1.30 $
+* @version $Revision: 1.31 $
*
* pbRevisions:/b
* pb20010709 andreas schaefer:/b
@@ -57,6 +58,8 @@
// Constants -
// Attributes
+ Category log = Category.getInstance(BMPPersistenceManager.class);
+
EntityContainer con;
Method ejbLoad;
@@ -126,8 +129,24 @@
{
if (methods[i].getName().equals(create))
{
-createMethods.put(methods[i], con.getBeanClass().getMethod(ejbCreate,
methods[i].getParameterTypes()));
-postCreateMethods.put(methods[i],
con.getBeanClass().getMethod(ejbPostCreate, methods[i].getParameterTypes()));
+try
+{
+ createMethods.put(methods[i],
con.getBeanClass().getMethod(ejbCreate, methods[i].getParameterTypes()));
+}
+catch (NoSuchMethodException e)
+{
+ log.error(Home Method + methods[i] + not implemented in bean
class);
+ throw e;
+}
+try
+{
+ postCreateMethods.put(methods[i],
con.getBeanClass().getMethod(ejbPostCreate, methods[i].getParameterTypes()));
+}
+catch (NoSuchMethodException e)
+{
+ log.error(Home Method + methods[i] + not implemented in bean
class);
+ throw e;
+}
}
}
@@ -136,7 +155,15 @@
{
if (methods[i].getName().startsWith(find))
{
-finderMethods.put(methods[i], con.getBeanClass().getMethod(ejbF +
methods[i].getName().substring(1), methods[i].getParameterTypes()));
+try
+{
+ finderMethods.put(methods[i], con.getBeanClass().getMethod(ejbF +
methods[i].getName().substring(1), methods[i].getParameterTypes()));
+}
+catch (NoSuchMethodException e)
+{
+ log.error(Home Method + methods[i] + not implemented in bean
class);
+ throw e;
+}
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
I am not quite sure if this is the way to go. You are starting with the master and then the slave hook up to this master (more ore less you create an administration server). When the master is going down the slaves run on their own and become zombies because all the configurations are on the master. My idea is that every server contains the configurations and the changes are propagated on all the other servers in the group. This would allow an administrator to pick up any server and able to manage the whole group. When any server goes down all the other server knows each others and can still propagate the changes and when a new server joins the group it can take the configuration from any other server and deploy the services and applications. Andy - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 2:12 PM Subject: Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling ! |I'm assuming that in a JBoss cluster Enterprise |Applications are distributed from one node (possibly a |Master) to all other nodes (possibly Slaves). I think to have a master which propagates the actions to the slaves is difficult when it comes to fail-over. It would be nice if the client doesn't know anything about a master but the logical server or view on top of the group of physical servers. I don't know if this master/slave stuff spawned from something I said, if so I want to clearify what I was talking about. If not, well then, here it is anyways =) When I was talking about master/slave, the master would trully be a dumb server, which had the sole responsiblity for starting up slave nodes, cycling them when they wedged, responing them when the jvm crashed and so on. The slave node in this view would be configured to run your application services. In a simple case, there would only be one slave for a master. The master would simply startup, then spawn the slave, watch for it to exit (as well as listen for lifecycle JMX events) and not really do more than that. By adding this small piece of architecture to the system, we can write applications that can replicate there environment automatically for fail over, provide a sandbox environment for applications that might run native libraries or be prone to sucking up memory with out endangering other critical services that must be runnining on the same machine. I think this will be important when it comes to really distributed uses of jboss in a mission critial application. Now that the configuration of the server can be loaded from a URL, the task of startup up new nodes is simply, looking up the URL to use. On boot, the task is simply looking up the list of URLs to load, then starting a JBoss slave node for each. To make somthing like this work, you need a configuration server, which is simply a JBoss node which is booted off of a file:// url, runs a web server and has some .jsp's which server up configurations to other nodes. A master node running on each machine, probably started up vi /etc/init.d/ or the equivilent on other operating systems. It is also a simple JBoss node, which pulls its config from http://configserver/master/ (perhaps with hostname, os and other params attached so the .jsp under master can dish out the correct config. The slaves looks mostly the same, the master looks up the url, which is probably http://configserver/slave/ (with the same os, arch, other fluff). If jini was used, then the act of finding the configserver could be more dynamic too. Doing something like this should be fairly simply too, the only hard bit is forking the master node and watching slave children. Java has some primitives to do this, but it could be abstracted out to an interface to allow native impls, which are more effective to be used in its place where available. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Message Driven Bean Error
Hi, I hope you can give me a little idea what goes wrong with my MDB. I really double checked all settings in jbossmq.xml, jboss.xml, ejb-jar.xml according to your example and am sure that anything should work because the error I get is happening after I start to send a message to the queue my mdb is listeneing on. I tried with jboss-2.2.2 and tomcat 3.2.2 and also using jboss-2.4.0 with tomcat 3.2.3 From the Log: ConnectionReceiver: Receive(ReceiveRequest[1]) SpyConnectionConsumer:Queue@testQueue mailto:SpyConnectionConsumer:Queue@testQueue-addMessage(mes=org.jbossmq.SpyObjectMessage@7cdb7e mailto:mes=org.jbossmq.SpyObjectMessage@7cdb7e) SpyConnectionConsumer:Queue@testQueue mailto:SpyConnectionConsumer:Queue@testQueue-processMessages() SpyConnectionConsumer:Queue@testQueue mailto:SpyConnectionConsumer:Queue@testQueue Starting the ServerSession. SpySession: run() 23:38:12 INFO [Thread Pool Worker:] JBossMQService.logToCategory Exception in JMSCI message listener: : java.lang.NoSuchMethodException In the error log I get the following stack trace: java.lang.NoSuchMethodException at java.lang.Class.getMethod0(Native Method) at java.lang.Class.getMethod(Class.java:888) at org.jboss.ejb.MessageDrivenEnterpriseContext.init(MessageDrivenEnterpriseContext.java:65) at org.jboss.ejb.plugins.MessageDrivenInstancePool.create(MessageDrivenInstancePool.java:48) at org.jboss.ejb.plugins.AbstractInstancePool.get(AbstractInstancePool.java:106) at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:50) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:128) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195) at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:281) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:150) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:495) at org.jbossmq.SpyMessageConsumer.deliverMessage(SpyMessageConsumer.java:296) at org.jbossmq.SpySession.run(SpySession.java:218) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:132) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655) at java.lang.Thread.run(Thread.java:484) I hope someone of you can get somthing out of these Information I am really frustrated because I have even not found any entry in the mailing list archives. Many thanks in advance Torsten Glunde ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss 3.0 / DataSource problem
Thank you. It works. -Message d'origine- De : David Jencks [mailto:[EMAIL PROTECTED]] Envoyé : mercredi 5 septembre 2001 23:30 À : [EMAIL PROTECTED] Cc : Dev JBoss Objet : Re: [JBoss-dev] Jboss 3.0 / DataSource problem One problem that causes this is escaped : ie \: in the jdbc url. right now the example .xml has jdbc\:HypersonicDatabase\:hsql\: Try jdbc:HypersonicDatabase:hsql:... marc's new ServiceDeployer removes all newlines from xml which messes up the property file format reading used in ConnectionFactoryLoader. My quick fix for ConnectionFactoryLoader didn't account for escaped :. Not sure how it got through my tests... I think I'll put the newlines back into the xml reader. david jencks On 2001.09.05 13:23:56 -0400 Vincent Harcq wrote: Hi, I have come to this problem before calling for help, I have mbean code=org.jboss.jdbc.JdbcProvider name=JBOSS-SYSTEM:service=JdbcProvider attribute name=Drivers com.inet.tds.TdsDriver, org.hsql.jdbcDriver /attribute /mbean BTW, this was enough and the add of Opta2000.jar in classpath archives=... was also needed. The Pool is created ok. It is at first SQL connection that badaboom. Regards. Vincent. -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoyé : mercredi 5 septembre 2001 19:09 À : [EMAIL PROTECTED]; Dev JBoss Objet : RE: [JBoss-dev] Jboss 3.0 / DataSource problem well, you still need to declare the JDBC driver in the JDBC MBean thingy. That is one of the things that we need to change, to have the connector declare what driver he is using as opposed to the kludgy MBean we have right now as a front end to loading the drivers. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Vincent Harcq |Sent: Wednesday, September 05, 2001 1:01 PM |To: Dev JBoss |Subject: [JBoss-dev] Jboss 3.0 / DataSource problem | | |Hi, |Running latest JBoss 3.0, |I have defined a datasource based on Opta2000 driver for MS SQL. |I have added the driver to the list of JDBC driver and the opta JAR to the |list of jar in top of jboss-service.xml. |I used the new way of configuring the pool, I simply copy/paste the one of |DefaultDS and changed the minimum. | |I got this exception while deploying an entity Bean. | |[JDBCManagedConnectionFactory-1] Unable to create ManagedConnection: |javax.resource.ResourceException: Unable to create DB connection: |java.sql.SQLException: No suitable driver |at |org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createMa |nagedConn |ection(JDBCManagedConnectionFactory.java:245) | |Does this say something to somebody ? | |Thanks. |Vincent. | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Missing JBoss_x_x tags?
Your missing something as the tags are there: /tmp 1145cvs co -r JBoss_2_4_0 jboss cvs server: Updating jboss cvs server: Updating jboss/build cvs server: Updating jboss/docs U jboss/docs/LICENSE.txt U jboss/docs/index.html U jboss/docs/styles.css cvs server: Updating jboss/etc cvs server: Updating jboss/external U jboss/external/connector.jar U jboss/external/rmiconnector.jar cvs server: Updating jboss/lib ... /tmp 1146cvs co -r JBoss_2_2_2 jboss cvs server: Updating jboss cvs server: Updating jboss/build cvs server: Updating jboss/docs cvs server: Updating jboss/etc cvs server: Updating jboss/external cvs server: Updating jboss/lib U jboss/lib/ant-1.3.jar U jboss/lib/awt.jar U jboss/lib/codegen.jar U jboss/lib/codegen.properties U jboss/lib/crimson.jar ... - Original Message - From: Luigi P. Bai [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 2:26 PM Subject: [JBoss-dev] Missing JBoss_x_x tags? I can't seem to cvs co -r JBoss_x_x anymore. I can't get source code tagged back to 2.2.2 or 2.4.0 ? Or am I missing something? I've browsed the cvs source at sourceforge.net, and the tags seem to have disappeared. ? --SIG A HREF=http://www.focalpoint.com/;Home Page/A education is what's left after what is learned is forgotten. -- b f skinner Luigi P. Bai Focal Point Software, Inc. [EMAIL PROTECTED] 3701 Kirby Drive, Suite 512 turning data into information Houston, TX 77098 (713) 215-1600 x 33# ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and J Boss MQ)
Hi, I don't have a very good feeling about having 2 kinds of dependency tree in the same file - the classpath one and the one you are proposing. Another approach that is used by the jca stuff and has been requested recently for the j2eedeployer is to use NotificationBroadcaster. 1. ServiceDeployer broadcasts notifications each time it deploys/undeploys a sar/jar/service.xml 2. If you have a dependency to a mbean in another package, you write your mbean to check for the object name when it is initialized, and to register for notifications. Whenever it gets a notification, it can check for deploy/undeploy of what it is looking for and go to an appropriate state. This should be pretty easy to code into ServiceMBeanSupport or a descendant so all you have to do is supply the object names you are looking for -- this could even be an attribute in the service.xml file. what do you think? thanks david jencks On 2001.09.05 17:39:15 -0400 David Maplesden wrote: OK just so everyone is clear (now that I have had some time to think about it) what I am proposing to do is as follows: In the jboss-service.xml (or equivalent xml snippet file) it will be possible to have depends tags dependsJBOSS-SYSTEM:service=Naming/depends that name an mbean or mbeans that must be deployed before the mbeans in the file itself can be deployed. The ServiceController will take notice of these tags and build a dependency list for the file. It will then delay the deployment of the file until all the mbeans on the list are deployed. This is to allow several files with interdependencies to be in the auto-deploy directory at the same time and have them deployed correctly. I could add a timeout to the waiting for the dependencies to resolved so that an exception is raised if the deployment seems to be halted indefinately. The mbeans listed within a single file will still be deployed in the order they are listed so that a large number of dependencies can be resolved by listing the mbeans in the same file. This mechanism though will allow us to specify services in separate jsr/sar's when it is useful to do so. This should be fairly simple to implement and relatively effective for our needs. I am not proposing any support for undeployment dependencies (automatically undeploying mbeans when mbeans they rely on are undeployed). The problem is quite a bit more complex. Any comments? David -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 9:17 AM To: David Maplesden Cc: JBossDev (E-mail) Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBoss MQ) Adding some form of dependency declaration will help improvde debugging, as a service (or rather the service controller) could throw an exception with the exact service name which is missing, instead of throwing other meaning less exceptions. Not that I really know that it does throw such exceptions, just pointing out that dependencies would help minimize the learning curve in some ways. I understand that it could also be confusing, but if it is left to a minimal design, simple in nature, then it should positivly augment the boot process rather than complicate it. --jason On Wed, 5 Sep 2001, David Maplesden wrote: Well it turns out it's not too hard to simply turn the MQ service into a jsr/sar and hot deploy from the deploy directory. However some problems turn up (of course) when you have other mbeans that rely on the MQ service. Obviously this is a problem faced by many mbeans, and it has been dealt with previously by listing the mbeans in a particular order within the jboss-service.xml file. Similarly the auto deployer has a feature where it scans the deployment directories in a particular order to ensure certain mbeans are deployed before others. However if I understand RH correctly the only reason we have anything listed in the jboss_service.xml file is to work around these dependencies, if we came up with a method of specifying the dependencies in the service.xml file then virtually everything (except the deployers themselves) could be deployed by the auto-deployer from the deploy directories. So what do people think about something like... ?xml version=1.0 encoding=UTF-8? server dependsJBOSS-SYSTEM:service=Naming/depends dependsJBOSS-SYSTEM:service=AnotherService/depends classpath archives=jbossmq.jar/ mbean code=org.jboss.mq.server.JBossMQService name=JBossMQ:service=Server/ *snip*snip* /server And then the deployer would delay the deployment of the mbeans in the xml file until the mbeans listed in depends tags are deployed as well as deploying the mbeans in the file in the order listed. This
Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
You are starting with the master and then the slave hook up to this master (more ore less you create an administration server). Not really, the only administration that is done by a master node is starting/stopping child nodes. That is it. When the master is going down the slaves run on their own and become zombies because all the configurations are on the master. No, the configuration is on the configserver, not the master node. If the master node goes down then its children will vote to see who will spawn a new master server, then attach to it. My idea is that every server contains the configurations and the changes are propagated on all the other servers in the group. This would allow an administrator to pick up any server and able to manage the whole group. When any server goes down all the other server knows each others and can still propagate the changes and when a new server joins the group it can take the configuration from any other server and deploy the services and applications. You could cluster the configserver and use jini as a fail over mechanism. Having each node keep updated configuration information is an uneeded burden, especially when configuration comes in the form of large files and such. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results
*TestCase is fine with me. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 12:55 PM Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results Can we rename, so that all test end with *Test.class, or *TestCase.class? I was looking into some of the errors yesterday, but did not really have any energy to do anything about it. I saw a few interfaces were thought to be tests and some odd naming problems. I also didn't see all of the tests on the output page again. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and J Boss MQ)
This is really an implementation detail of adding dependsxxx/depends element. What is the difference between having a depends attribute or element? - Original Message - From: David Jencks [EMAIL PROTECTED] To: David Maplesden [EMAIL PROTECTED] Cc: JBossDev [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 3:24 PM Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and J Boss MQ) Hi, I don't have a very good feeling about having 2 kinds of dependency tree in the same file - the classpath one and the one you are proposing. Another approach that is used by the jca stuff and has been requested recently for the j2eedeployer is to use NotificationBroadcaster. 1. ServiceDeployer broadcasts notifications each time it deploys/undeploys a sar/jar/service.xml 2. If you have a dependency to a mbean in another package, you write your mbean to check for the object name when it is initialized, and to register for notifications. Whenever it gets a notification, it can check for deploy/undeploy of what it is looking for and go to an appropriate state. This should be pretty easy to code into ServiceMBeanSupport or a descendant so all you have to do is supply the object names you are looking for -- this could even be an attribute in the service.xml file. what do you think? thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results
I plan on getting to this shortly. I want to create a JBossTestSuite and force all tests to extend from it at the same time. --jason On Wed, 5 Sep 2001, Scott M Stark wrote: *TestCase is fine with me. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 12:55 PM Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results Can we rename, so that all test end with *Test.class, or *TestCase.class? I was looking into some of the errors yesterday, but did not really have any energy to do anything about it. I saw a few interfaces were thought to be tests and some odd naming problems. I also didn't see all of the tests on the output page again. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Deployment Dependencies (was RE: [JBoss-dev] RH startup and J Boss MQ)
I think the argument is really about whether we list the dependents as mbeans or jsr/sar files. The problem with using Notifications is that it has to be coded into the mbeans themselves. Fine if people extend ServiceMBeanSupport and we can code it in there, but there is no requirement for mbean developers to extend ServiceMBeanSupport and I feel we should have a mechanism to handle dependencies specified for any mbeans, not have to rely on mbean developers. This does not mean that the Notifications are not a good thing to have, they probably are, but I think we need another mechanism as well. So that leaves us with basically two proposals, use the archives listed in the classpath element as David Jencks suggests or list the dependent mbeans explicitly in depends elements as I suggested. I actually think there is room for both mechanisms to a certain extent as there purpose is to achieve different things. David J's mechanism seems to be aimed mainly at the automatic deploying and undeploying of an application that is split across several jsr/sars while mine is mainly for guaranteeing that all required services for an application exist before it is loaded. Anyway the vote seems to be 1-all at the moment, anyone else? :) David -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 10:58 AM To: JBossDev Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and J Boss MQ) This is really an implementation detail of adding dependsxxx/depends element. What is the difference between having a depends attribute or element? - Original Message - From: David Jencks [EMAIL PROTECTED] To: David Maplesden [EMAIL PROTECTED] Cc: JBossDev [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 3:24 PM Subject: Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and J Boss MQ) Hi, I don't have a very good feeling about having 2 kinds of dependency tree in the same file - the classpath one and the one you are proposing. Another approach that is used by the jca stuff and has been requested recently for the j2eedeployer is to use NotificationBroadcaster. 1. ServiceDeployer broadcasts notifications each time it deploys/undeploys a sar/jar/service.xml 2. If you have a dependency to a mbean in another package, you write your mbean to check for the object name when it is initialized, and to register for notifications. Whenever it gets a notification, it can check for deploy/undeploy of what it is looking for and go to an appropriate state. This should be pretty easy to code into ServiceMBeanSupport or a descendant so all you have to do is supply the object names you are looking for -- this could even be an attribute in the service.xml file. what do you think? thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] To - JINI - or to - Narrowcast ...
Sisters, IT IS only semantics that hinder Us --- sometimes ... Please Imagine : *- Step One - Somebody walks into and hook (ethernet / wire / Radio / ?) a device into the area - then the DCHP server of that area - able -net would deliver a IP to my mobile(maybe to become static) host ! ... and a JINI identity (personality) exchange would take place ... **- Step Two - In Our concern here - I would then, start a seed of JBoss, and throughout self-discovery, it would then d-load the latest version of JBoss into my mobile(or to become static) host ! ... coool ... That's a JINI scenario ... *** What We want (except being seduced by the concept of --- self-discovery) is a less expedite host in the cluster - unless explicitly asked for ...We want !? ... to use JavaGroups Broadcast, since it is more solid / valid !? for Our purpose ... *** So ... Now ... Broadcast as a concept is ~blurry~ - when used - in conjunction with the net !, born in television. We have tried and just swamp the net (Broadcast = everybody --- thats 32 million + addresses in ip4) ... Broadcast on the net is a last century academic wet pleasure ***still it can be used by Our product (semantics) ... in that a broadcast with a TTL (Time To Live) of 0 would not go pass the first router sent from ... this, could then be called a narrowcast ... (-while using a broadcast - a oxymoron -heh) h ... oki - a broadcast inside my router spans TTL, would have all my machines inside that TTL's network layer to revive and look at all the packets sent/broadcasted/narrowcasted ... these packets *is* valid for my JBoss cluster ! (who is going to live inside my routed routed TTL anyway ? ). I am here imagining the JBoss cluster living inside a controlled routed c-net !? ... and broadcast with a TTL of 0 will be relevant for Me !? ... Look at any routed net (ethernet) and one will find alot of noice thats not relevant for my networklayers service - but my networklayer and its service has to look at it before it can say : - drop - service - warn and there is still time ! to service the packets that has relevance ... What i am trying to say in thatn many words is - that a controlled broadcast is useful ... and not limiting at all ... !!! ... ;-) /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and J Boss MQ)
Let's not couple dependency management to JMX notifications. - Original Message - From: David Maplesden [EMAIL PROTECTED] To: 'Scott M Stark' [EMAIL PROTECTED]; JBossDev [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 3:59 PM Subject: RE: Deployment Dependencies (was RE: [JBoss-dev] RH startup and J Boss MQ) I think the argument is really about whether we list the dependents as mbeans or jsr/sar files. The problem with using Notifications is that it has to be coded into the mbeans themselves. Fine if people extend ServiceMBeanSupport and we can code it in there, but there is no requirement for mbean developers to extend ServiceMBeanSupport and I feel we should have a mechanism to handle dependencies specified for any mbeans, not have to rely on mbean developers. This does not mean that the Notifications are not a good thing to have, they probably are, but I think we need another mechanism as well. So that leaves us with basically two proposals, use the archives listed in the classpath element as David Jencks suggests or list the dependent mbeans explicitly in depends elements as I suggested. I actually think there is room for both mechanisms to a certain extent as there purpose is to achieve different things. David J's mechanism seems to be aimed mainly at the automatic deploying and undeploying of an application that is split across several jsr/sars while mine is mainly for guaranteeing that all required services for an application exist before it is loaded. Anyway the vote seems to be 1-all at the moment, anyone else? :) David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
i.e. Abstract out the Master/Slave components and put one of each on each node, instead. If you did this cleverly you would be able to deploy either architecture or combinations with e.g. 3 masters and n-slaves, or you could even copy your architecture from a place at which I worked, where the Masters outnumber the Slaves ! Jules Andreas Schaefer wrote: I am not quite sure if this is the way to go. You are starting with the master and then the slave hook up to this master (more ore less you create an administration server). When the master is going down the slaves run on their own and become zombies because all the configurations are on the master. My idea is that every server contains the configurations and the changes are propagated on all the other servers in the group. This would allow an administrator to pick up any server and able to manage the whole group. When any server goes down all the other server knows each others and can still propagate the changes and when a new server joins the group it can take the configuration from any other server and deploy the services and applications. Andy - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 2:12 PM Subject: Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling ! |I'm assuming that in a JBoss cluster Enterprise |Applications are distributed from one node (possibly a |Master) to all other nodes (possibly Slaves). I think to have a master which propagates the actions to the slaves is difficult when it comes to fail-over. It would be nice if the client doesn't know anything about a master but the logical server or view on top of the group of physical servers. I don't know if this master/slave stuff spawned from something I said, if so I want to clearify what I was talking about. If not, well then, here it is anyways =) When I was talking about master/slave, the master would trully be a dumb server, which had the sole responsiblity for starting up slave nodes, cycling them when they wedged, responing them when the jvm crashed and so on. The slave node in this view would be configured to run your application services. In a simple case, there would only be one slave for a master. The master would simply startup, then spawn the slave, watch for it to exit (as well as listen for lifecycle JMX events) and not really do more than that. By adding this small piece of architecture to the system, we can write applications that can replicate there environment automatically for fail over, provide a sandbox environment for applications that might run native libraries or be prone to sucking up memory with out endangering other critical services that must be runnining on the same machine. I think this will be important when it comes to really distributed uses of jboss in a mission critial application. Now that the configuration of the server can be loaded from a URL, the task of startup up new nodes is simply, looking up the URL to use. On boot, the task is simply looking up the list of URLs to load, then starting a JBoss slave node for each. To make somthing like this work, you need a configuration server, which is simply a JBoss node which is booted off of a file:// url, runs a web server and has some .jsp's which server up configurations to other nodes. A master node running on each machine, probably started up vi /etc/init.d/ or the equivilent on other operating systems. It is also a simple JBoss node, which pulls its config from http://configserver/master/ (perhaps with hostname, os and other params attached so the .jsp under master can dish out the correct config. The slaves looks mostly the same, the master looks up the url, which is probably http://configserver/slave/ (with the same os, arch, other fluff). If jini was used, then the act of finding the configserver could be more dynamic too. Doing something like this should be fairly simply too, the only hard bit is forking the master node and watching slave children. Java has some primitives to do this, but it could be abstracted out to an interface to allow native impls, which are more effective to be used in its place where available. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
The master/slave bits that I went over are simply to move the problem of starting up native processes up into the control of JBoss, rather than relying on os dependent stuff. Could you explain the architecture where masters slaves? --jason On Thu, 6 Sep 2001, Julian Gosnell wrote: i.e. Abstract out the Master/Slave components and put one of each on each node, instead. If you did this cleverly you would be able to deploy either architecture or combinations with e.g. 3 masters and n-slaves, or you could even copy your architecture from a place at which I worked, where the Masters outnumber the Slaves ! Jules Andreas Schaefer wrote: I am not quite sure if this is the way to go. You are starting with the master and then the slave hook up to this master (more ore less you create an administration server). When the master is going down the slaves run on their own and become zombies because all the configurations are on the master. My idea is that every server contains the configurations and the changes are propagated on all the other servers in the group. This would allow an administrator to pick up any server and able to manage the whole group. When any server goes down all the other server knows each others and can still propagate the changes and when a new server joins the group it can take the configuration from any other server and deploy the services and applications. Andy - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 2:12 PM Subject: Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling ! |I'm assuming that in a JBoss cluster Enterprise |Applications are distributed from one node (possibly a |Master) to all other nodes (possibly Slaves). I think to have a master which propagates the actions to the slaves is difficult when it comes to fail-over. It would be nice if the client doesn't know anything about a master but the logical server or view on top of the group of physical servers. I don't know if this master/slave stuff spawned from something I said, if so I want to clearify what I was talking about. If not, well then, here it is anyways =) When I was talking about master/slave, the master would trully be a dumb server, which had the sole responsiblity for starting up slave nodes, cycling them when they wedged, responing them when the jvm crashed and so on. The slave node in this view would be configured to run your application services. In a simple case, there would only be one slave for a master. The master would simply startup, then spawn the slave, watch for it to exit (as well as listen for lifecycle JMX events) and not really do more than that. By adding this small piece of architecture to the system, we can write applications that can replicate there environment automatically for fail over, provide a sandbox environment for applications that might run native libraries or be prone to sucking up memory with out endangering other critical services that must be runnining on the same machine. I think this will be important when it comes to really distributed uses of jboss in a mission critial application. Now that the configuration of the server can be loaded from a URL, the task of startup up new nodes is simply, looking up the URL to use. On boot, the task is simply looking up the list of URLs to load, then starting a JBoss slave node for each. To make somthing like this work, you need a configuration server, which is simply a JBoss node which is booted off of a file:// url, runs a web server and has some .jsp's which server up configurations to other nodes. A master node running on each machine, probably started up vi /etc/init.d/ or the equivilent on other operating systems. It is also a simple JBoss node, which pulls its config from http://configserver/master/ (perhaps with hostname, os and other params attached so the .jsp under master can dish out the correct config. The slaves looks mostly the same, the master looks up the url, which is probably http://configserver/slave/ (with the same os, arch, other fluff). If jini was used, then the act of finding the configserver could be more dynamic too. Doing something like this should be fairly simply too, the only hard bit is forking the master node and watching slave children. Java has some primitives to do this, but it could be abstracted out to an interface to allow native impls, which are more effective to be used in its place where available. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Depend ...
If I could have JBoss - be a family of services -then it should, be able to, undeploy for ex. MQ andredploy without distubence to sevices dependent of MQ!. how ? Maybe interceptor paus - or go live before switch ? and then undeploy old ? ... /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] manual filtering
The copy steps with filtering are not producing valid href values on w2k.
The
problem is that the oasis.docbook.xsl.root property and filter are not valid
absolute paths for insertion into a file:://xxx url. Here is a simple ant
script
that demonstrates the problem:
manual 675cat tst.xml
project default=main name=JBoss/Manual
path id=project.rootpathelement location=..//path
property name=project.root refid=project.root/
property name=thirdparty.root value=${project.root}/thirdparty/
path id=oasis.docbook.xsl.root
pathelement location=${thirdparty.root}/oasis/docbook-xml/
/path
property name=oasis.docbook.xsl.root refid=oasis.docbook.xsl.root/
target name=main
echo message=oasis.docbook.xsl.root = ${oasis.docbook.xsl.root} /
filter token=oasis.docbook.xsl.root
value=${oasis.docbook.xsl.root}/
copy todir=. file=src/stylesheets/fancy.xsl filtering=yes /
/target
/project
When run it produces a filtered fancy.xsl file that fails to be parsed by
the transformer.
The problem is with the resulting file urls:
manual 673ant -buildfile tst.xml
Buildfile: tst.xml
main:
[echo] oasis.docbook.xsl.root =
D:\usr\local\src\cvsroot\Main\jboss-all\thirdparty\oasis\docbook-xml
The resulting href in the filtered fancy.xsl file is:
xsl:import
href=file://D:\usr\local\src\cvsroot\Main\jboss-all\thirdparty\oasis\docboo
k-xml/html/chunk.xsl/
it needs to be:
xsl:import
href=file:///D:\usr\local\src\cvsroot\Main\jboss-all\thirdparty\oasis\docbo
ok-xml/html/chunk.xsl/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Depend ...
Hi, I have here a version of ServiceDeployer that does this at the jsr/sar level. You can specify which sar's a given sar depends on, then it works like this: B depends on A deploy A, then deploy B Undeploy A B undeployed redeploy A - B redeployed. Actually it will do fancier stuff than this, this is a simple example. I sent it to Marc last night but haven't heard back from him. maybe it will be in cvs soon. david jencks On 2001.09.05 19:40:10 -0400 Peter Fagerlund wrote: If I could have JBoss - be a family of services -then it should, be able to, undeploy for ex. MQ andredploy without distubence to sevices dependent of MQ!. how ? Maybe interceptor paus - or go live before switch ? and then undeploy old ? ... /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Is mail return acting peculiar?
Is it just my mail client or are all the messages from jboss-dev replying to the author rather than the list? THis is a sourceforge setting, did it get messed up? david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty Jetty.java
User: jules_gosnell Date: 01/09/05 17:02:09 Modified:jetty/src/main/org/jboss/jetty Jetty.java Log: relocate jboss-web.dtd which seems to have moved Revision ChangesPath 1.14 +1 -1 contrib/jetty/src/main/org/jboss/jetty/Jetty.java Index: Jetty.java === RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Jetty.java,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- Jetty.java2001/08/09 20:57:22 1.13 +++ Jetty.java2001/09/06 00:02:09 1.14 @@ -39,7 +39,7 @@ URL stdWeb=findResourceInJar(com.mortbay.HTTP.HttpServer,com/mortbay/Jetty/Servlet/web.dtd); _resolver.put(-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN, stdWeb); -URL jbossWeb=findResourceInJar(org.jboss.jetty.JettyService,jboss-web.dtd); +URL jbossWeb=findResourceInJar(org.jboss.web.AbstractWebContainer,org/jboss/metadata/jboss-web.dtd); _resolver.put(-//jBoss//DTD Web Application 2.2//EN, jbossWeb); _resolver.put(-//JBoss//DTD Web Application 2.2//EN, jbossWeb); } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RH build problem....
Jason, I've been trying to run web tests to get Jetty up and running properly - this is a strange one Try this in testsuite. sh ./build.sh -Dtest=web clean test - don't worry about it failing [jules@zeuglodon testsuite]$ ls -l `find . -name soap*.jar` -rw-rw-r--1 julesjules 220746 Sep 6 01:33 ./output/resources/web/WEB-INF/lib/soap-2_2.jar -rw-rw-r--1 julesjules 220750 Jun 27 11:09 ./src/resources/web/WEB-INF/lib/soap-2_2.jar [jules@zeuglodon testsuite]$ [jules@zeuglodon testsuite]$ jar tvf ./output/resources/web/WEB-INF/lib/soap-2_2.jar 0 Tue Jun 26 13:44:22 BST 2001 META-INF/ java.util.zip.ZipException: invalid entry CRC (expected 0xc7322017 but got 0xde9b8379) at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:365) at java.util.zip.ZipInputStream.read(ZipInputStream.java:144) at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:93) at sun.tools.jar.Main.list(Main.java:744) at sun.tools.jar.Main.run(Main.java:193) at sun.tools.jar.Main.main(Main.java:904) [jules@zeuglodon testsuite]$ Perhaps I'm losing my mind. but this looks like an ant bug Unsurprisingly, when someone calls the MessageRouterServlet Jetty complains javax.servlet.UnavailableException: java.lang.ClassNotFoundException: org.apache.soap.server.http.MessageRouterServlet at com.mortbay.Jetty.Servlet.ServletHolder.initializeClass(ServletHolder.java:263) at com.mortbay.Jetty.Servlet.ServletHandler.start(ServletHandler.java:200) at com.mortbay.HTTP.HandlerContext.start(HandlerContext.java:1081) at com.mortbay.Jetty.Servlet.WebApplicationContext.start(WebApplicationContext.java:354) at org.jboss.jetty.Jetty.deploy(Jetty.java:196) at org.jboss.jetty.JettyService.performDeploy(JettyService.java:258) at org.jboss.web.AbstractWebContainer.deploy(AbstractWebContainer.java:185) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:501) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:464) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:208) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.jmx.server.JMXAdaptorImpl.invoke(JMXAdaptorImpl.java:69) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run(Transport.java:152) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706) at java.lang.Thread.run(Thread.java:484) getRootCause(): If you get past this problem, I have checked back in a couple of changes which should fix some stuff. You might want to remove all excess stuff from your jett.xml in conf/Default to get Jetty to work cleanly - I simply set JettyHome in jboss-service.xml to point at a valid Jetty-3.1.RC8 tree - no problemo. Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss-service.xml
User: jules_gosnell Date: 01/09/05 17:39:34 Modified:src/etc/conf/default jboss-service.xml Log: seeing as we seem to be using Jetty by default now - make sure the J2EEDeployer knows about it... Revision ChangesPath 1.4 +2 -2 jboss/src/etc/conf/default/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss-service.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jboss-service.xml 2001/08/31 04:28:48 1.3 +++ jboss-service.xml 2001/09/06 00:39:34 1.4 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: jboss-service.xml,v 1.3 2001/08/31 04:28:48 chirino Exp $ -- +!-- $Id: jboss-service.xml,v 1.4 2001/09/06 00:39:34 jules_gosnell Exp $ -- !-- | This is where you can add and configure your MBeans. @@ -586,7 +586,7 @@ name=J2EE:service=J2eeDeployer attribute name=DeployerNameDefault/attribute attribute name=JarDeployerName:service=ContainerFactory/attribute -attribute name=WarDeployerName:service=EmbeddedTomcat/attribute +attribute name=WarDeployerName:service=Jetty/attribute /mbean !-- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is mail return acting peculiar?
I haven't changed anything. Perhaps the sourceforge defaults have changed. Looking at the list admin page the default, and in sourceforge words strongly recommended, is to reply to the poster. - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 5:08 PM Subject: [JBoss-dev] Is mail return acting peculiar? Is it just my mail client or are all the messages from jboss-dev replying to the author rather than the list? THis is a sourceforge setting, did it get messed up? david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: RH build problem....
soap-2.2.jar should really be pulled from thirdparty/... My guess is that the copy task is filtering, which is corrupting this file. I would like to not disable filtering for text based files, but that might be the easiest way to fix this. --jason On Thu, 6 Sep 2001, Julian Gosnell wrote: Jason, I've been trying to run web tests to get Jetty up and running properly - this is a strange one Try this in testsuite. sh ./build.sh -Dtest=web clean test - don't worry about it failing [jules@zeuglodon testsuite]$ ls -l `find . -name soap*.jar` -rw-rw-r--1 julesjules 220746 Sep 6 01:33 ./output/resources/web/WEB-INF/lib/soap-2_2.jar -rw-rw-r--1 julesjules 220750 Jun 27 11:09 ./src/resources/web/WEB-INF/lib/soap-2_2.jar [jules@zeuglodon testsuite]$ [jules@zeuglodon testsuite]$ jar tvf ./output/resources/web/WEB-INF/lib/soap-2_2.jar 0 Tue Jun 26 13:44:22 BST 2001 META-INF/ java.util.zip.ZipException: invalid entry CRC (expected 0xc7322017 but got 0xde9b8379) at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:365) at java.util.zip.ZipInputStream.read(ZipInputStream.java:144) at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:93) at sun.tools.jar.Main.list(Main.java:744) at sun.tools.jar.Main.run(Main.java:193) at sun.tools.jar.Main.main(Main.java:904) [jules@zeuglodon testsuite]$ Perhaps I'm losing my mind. but this looks like an ant bug Unsurprisingly, when someone calls the MessageRouterServlet Jetty complains javax.servlet.UnavailableException: java.lang.ClassNotFoundException: org.apache.soap.server.http.MessageRouterServlet at com.mortbay.Jetty.Servlet.ServletHolder.initializeClass(ServletHolder.java:263) at com.mortbay.Jetty.Servlet.ServletHandler.start(ServletHandler.java:200) at com.mortbay.HTTP.HandlerContext.start(HandlerContext.java:1081) at com.mortbay.Jetty.Servlet.WebApplicationContext.start(WebApplicationContext.java:354) at org.jboss.jetty.Jetty.deploy(Jetty.java:196) at org.jboss.jetty.JettyService.performDeploy(JettyService.java:258) at org.jboss.web.AbstractWebContainer.deploy(AbstractWebContainer.java:185) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:501) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:464) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:208) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.jmx.server.JMXAdaptorImpl.invoke(JMXAdaptorImpl.java:69) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run(Transport.java:152) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706) at java.lang.Thread.run(Thread.java:484) getRootCause(): If you get past this problem, I have checked back in a couple of changes which should fix some stuff. You might want to remove all excess stuff from your jett.xml in conf/Default to get Jetty to work cleanly - I simply set JettyHome in jboss-service.xml to point at a valid Jetty-3.1.RC8 tree - no problemo. Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] manual filtering
I think the pathconvert task from ant 1.4 will help fix this, but I need to
update the build system to move all config into a target before I fix this.
I am testing this new configuration now.
--jason
On Wed, 5 Sep 2001, Scott M Stark wrote:
The copy steps with filtering are not producing valid href values on w2k.
The
problem is that the oasis.docbook.xsl.root property and filter are not valid
absolute paths for insertion into a file:://xxx url. Here is a simple ant
script
that demonstrates the problem:
manual 675cat tst.xml
project default=main name=JBoss/Manual
path id=project.rootpathelement location=..//path
property name=project.root refid=project.root/
property name=thirdparty.root value=${project.root}/thirdparty/
path id=oasis.docbook.xsl.root
pathelement location=${thirdparty.root}/oasis/docbook-xml/
/path
property name=oasis.docbook.xsl.root refid=oasis.docbook.xsl.root/
target name=main
echo message=oasis.docbook.xsl.root = ${oasis.docbook.xsl.root} /
filter token=oasis.docbook.xsl.root
value=${oasis.docbook.xsl.root}/
copy todir=. file=src/stylesheets/fancy.xsl filtering=yes /
/target
/project
When run it produces a filtered fancy.xsl file that fails to be parsed by
the transformer.
The problem is with the resulting file urls:
manual 673ant -buildfile tst.xml
Buildfile: tst.xml
main:
[echo] oasis.docbook.xsl.root =
D:\usr\local\src\cvsroot\Main\jboss-all\thirdparty\oasis\docbook-xml
The resulting href in the filtered fancy.xsl file is:
xsl:import
href=file://D:\usr\local\src\cvsroot\Main\jboss-all\thirdparty\oasis\docboo
k-xml/html/chunk.xsl/
it needs to be:
xsl:import
href=file:///D:\usr\local\src\cvsroot\Main\jboss-all\thirdparty\oasis\docbo
ok-xml/html/chunk.xsl/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458680 ] Too verbous output for JBossMQ
Bugs item #458680, was opened at 2001-09-05 04:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=458680group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Aleksey Studnev (studnev) Assigned to: Nobody/Anonymous (nobody) Summary: Too verbous output for JBossMQ Initial Comment: File jbossmq.properties contains by default: # [Log level] valid values are : LOG_EVERYTHING, LOG_NOTICE, LOG_ERRORS LogLevel = LOG_EVERYTHING LOG_EVERYTHING is not a good default choice, should be LOG_ERRORS -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=458680group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: RH build problem....
How is a jar a text based file? Your doing copy tasks with filtering=yes all over the place which is not the default behavior, and was not the behavior used by any of the testsuite scripts. Combine this with the fact that all properties are filters and there are bound to be problems copying jars. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Julian Gosnell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 6:05 PM Subject: [JBoss-dev] Re: RH build problem soap-2.2.jar should really be pulled from thirdparty/... My guess is that the copy task is filtering, which is corrupting this file. I would like to not disable filtering for text based files, but that might be the easiest way to fix this. --jason On Thu, 6 Sep 2001, Julian Gosnell wrote: Jason, I've been trying to run web tests to get Jetty up and running properly - this is a strange one Try this in testsuite. sh ./build.sh -Dtest=web clean test - don't worry about it failing [jules@zeuglodon testsuite]$ ls -l `find . -name soap*.jar` -rw-rw-r--1 julesjules 220746 Sep 6 01:33 ./output/resources/web/WEB-INF/lib/soap-2_2.jar -rw-rw-r--1 julesjules 220750 Jun 27 11:09 ./src/resources/web/WEB-INF/lib/soap-2_2.jar [jules@zeuglodon testsuite]$ [jules@zeuglodon testsuite]$ jar tvf ./output/resources/web/WEB-INF/lib/soap-2_2.jar 0 Tue Jun 26 13:44:22 BST 2001 META-INF/ java.util.zip.ZipException: invalid entry CRC (expected 0xc7322017 but got 0xde9b8379) at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:365) at java.util.zip.ZipInputStream.read(ZipInputStream.java:144) at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:93) at sun.tools.jar.Main.list(Main.java:744) at sun.tools.jar.Main.run(Main.java:193) at sun.tools.jar.Main.main(Main.java:904) [jules@zeuglodon testsuite]$ Perhaps I'm losing my mind. but this looks like an ant bug Unsurprisingly, when someone calls the MessageRouterServlet Jetty complains javax.servlet.UnavailableException: java.lang.ClassNotFoundException: org.apache.soap.server.http.MessageRouterServlet at com.mortbay.Jetty.Servlet.ServletHolder.initializeClass(ServletHolder.java:2 63) at com.mortbay.Jetty.Servlet.ServletHandler.start(ServletHandler.java:200) at com.mortbay.HTTP.HandlerContext.start(HandlerContext.java:1081) at com.mortbay.Jetty.Servlet.WebApplicationContext.start(WebApplicationContext. java:354) at org.jboss.jetty.Jetty.deploy(Jetty.java:196) at org.jboss.jetty.JettyService.performDeploy(JettyService.java:258) at org.jboss.web.AbstractWebContainer.deploy(AbstractWebContainer.java:185) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:501) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:464) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:208) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.jmx.server.JMXAdaptorImpl.invoke(JMXAdaptorImpl.java:69) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run(Transport.java:152) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:7 06) at java.lang.Thread.run(Thread.java:484) getRootCause(): If you get past this problem, I have checked back in a couple of changes which should fix some stuff. You might want to remove all excess stuff from your jett.xml in conf/Default to get Jetty to work cleanly - I simply set JettyHome in jboss-service.xml to point at a valid Jetty-3.1.RC8 tree - no problemo. Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458682 ] Persistent message storage not scalable
Bugs item #458682, was opened at 2001-09-05 04:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=458682group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Aleksey Studnev (studnev) Assigned to: Nobody/Anonymous (nobody) Summary: Persistent message storage not scalable Initial Comment: After sending many messages to JBossMQ ( all were received and removed from queue or topic) stop JBoss and start again. It takes a lot of time to start-up, more than any reasonable time if you received, say 1 million messages. Also the length of files in jbossmq database are increasing endlessly. Finally the disk will be full and i will not be able to start JBoss. Right now i delete these files manually, but i can delete messages which were not yet received and acknowldedged. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=458682group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458728 ] EOFException happens periodically in log
Bugs item #458728, was opened at 2001-09-05 07:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=458728group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Aleksey Studnev (studnev) Assigned to: Nobody/Anonymous (nobody) Summary: EOFException happens periodically in log Initial Comment: java.io.EOFException at java.io.ObjectInputStream.readByte (ObjectInputStream.java:1907) at org.jbossmq.distributed.server.ConnectionReceiverOIL.ru n(ConnectionReceiverOIL.java:111) at java.lang.Thread.run(Thread.java:484) java.io.EOFException at java.io.ObjectInputStream.readByte (ObjectInputStream.java:1907) at org.jbossmq.distributed.server.ConnectionReceiverOIL.ru n(ConnectionReceiverOIL.java:111) at java.lang.Thread.run(Thread.java:484) java.io.EOFException at java.io.ObjectInputStream.readByte (ObjectInputStream.java:1907) at org.jbossmq.distributed.server.ConnectionReceiverOIL.ru n(ConnectionReceiverOIL.java:111) at java.lang.Thread.run(Thread.java:484) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=458728group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: RH build problem....
How is a jar a text based file? Your doing copy tasks with filtering=yes all over the place which is not the default behavior, and was not the behavior used by any of the testsuite scripts. True. I have found filters to be very useful, and thus I turned them on in most places. We could simply turn it off, though there are some which need to be enabled (like the manual/src/xdocs copies, so that the docbook refs are correct, once the path has been converted property of course). Combine this with the fact that all properties are filters and there are bound to be problems copying jars. Jars and other binary files should not be filtered at all. I don't see how having all properties be filters has anything to do with this. So far there have been two places (that I know of so far) where filtering has caused problems, one was the copy of the manual images (fixed) and the other is this copy of the soap-2.2.jar (which should be moved to thirdparty). If there are other problems due to filtering I am not aware of them at the present. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: RH build problem....
We shouldn't be. I didn't realize that the new system was using filtering so pervasively until this issue showed up. - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 6:41 PM Subject: Re: [JBoss-dev] Re: RH build problem I don't get it... why are we filtering?? Wasn't everything working with old build system without filtering??? Regards, HIram From: Scott M Stark [EMAIL PROTECTED] Reply-To: Scott M Stark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Re: RH build problem Date: Wed, 5 Sep 2001 18:29:29 -0700 How is a jar a text based file? Your doing copy tasks with filtering=yes all over the place which is not the default behavior, and was not the behavior used by any of the testsuite scripts. Combine this with the fact that all properties are filters and there are bound to be problems copying jars. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Julian Gosnell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 6:05 PM Subject: [JBoss-dev] Re: RH build problem soap-2.2.jar should really be pulled from thirdparty/... My guess is that the copy task is filtering, which is corrupting this file. I would like to not disable filtering for text based files, but that might be the easiest way to fix this. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: RH build problem....
I don't get it... why are we filtering?? Wasn't everything working with old build system without filtering??? That really depends by what is meant by working. I would not consider the old build system as working, and thus spent lots of time trying to fix it, which I think went well for the most part. I enabled filtering by default an all source copies (which I expected to be text not binary), to allow those files to pickup configuration from the build system. I think that it is beneficial, though currently it is only being used in two places (version.properties and the manual/src/xdocs stuff). If it is causing a fuss, then we can simply drop the default fitering and only filter those files which need to be. This will complicate the build system slightly, since you will have to have additional copy tasks with filtering enabled, which include the select files, then the regular copy tasks will have to exlude those files and such. I prefer the filters, but I don't really care either way. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458826 ] ANT
Bugs item #458826, was opened at 2001-09-05 11:38
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=458826group_id=22866
Category: JBossDoc
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ANT
Initial Comment:
I was going through the examples in Chapter 5 for
testing the client for the CD demo, it says:
To run this client run ant cmp-cd-list.
However if you run this it can't find ${client}
So in the build.xml I changed
target name=cmp-cd-list depends=init
ant antfile=org/jboss/docs/cmp/cd/build/build-
client.xml target=main /
/target
to
target name=cmp-cd-list depends=init
property name=client value=List /
ant antfile=org/jboss/docs/cmp/cd/build/build-
client.xml target=main /
/target
This works fine.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=458826group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] The trouble with ClassLoaders.
I am getting some odd behaviour with the loading of classes since marc's RH
changes and after spending a couple of days testing things out and trying to
convince myself I'm not going mad I've nearly given up trying to figure out
whats going on.
I basically want to know if anyone else is getting any of these (seemingly
unrelated) problems and and/or whether anyone else knows if I am just plain
doing things wrong. None of these problems occur with pre-RH JBoss 2.5.
1) The DefaultDS DataSource throws an SQLException No suitable driver when
I try to get a connection even though it seems to initialise correctly and
the jdbcProvider successfully loaded the org.hsql.jdbcDriver.
Snippets from log...
[JdbcProvider,INFO] Initializing
[JdbcProvider,INFO] Loaded JDBC-driver:org.hsql.jdbcDriver
[JdbcProvider,INFO] Initialized
followed by...
[DefaultDS,INFO] Starting
[DefaultDS,INFO] Started
and finally...
[JDBCManagedConnectionFactory-1,ERROR] Unable to create ManagedConnection:
javax.resource.ResourceException: Unable to create DB connection
(url=jdbc\:HypersonicSQL\:hsql\://localhost\:1476, user=sa:
java.sql.SQLException: No suitable driver
at
org.jboss.pool.connector.jdbc.JDBCManagedConnectionFactory.createManagedConn
ection(JDBCManagedConnectionFactory.java:245)
at
org.jboss.pool.connector.ManagedConnectionPoolFactory.createObject(ManagedCo
nnectionPoolFactory.java:62)
at org.jboss.pool.ObjectPool.createNewObject(ObjectPool.java:991)
at org.jboss.pool.ObjectPool.getObject(ObjectPool.java:657)
at
org.jboss.pool.connector.SharedLocalConnectionManager.allocateConnection(Sha
redLocalConnectionManager.java:104)
at
org.jboss.pool.connector.jdbc.JDBCDataSource.getConnection(JDBCDataSource.ja
va:79)
2) Originally Jetty failed every time it tried to compile a jsp page because
it can't find the javax.servlet.* classes, even though I had them in the
lib/ext directory (in javax.servlet.jar) along with everything else. Then I
added the javax.servlet.jar as a standard extension to my jdk and now it
can't find some of the jasper classes, although it finds others. The error
message below comes from a jasper class because it can't find another jasper
class, even though they are both in the same jar file! Jetty also serves
servlets fine.
[Jetty,WARN] Servlet Exception for /demo/jsp/hello.jsp
org.apache.jasper.JasperException: JASPER: Unable to compile class for
JSPC:\DOCUME~1\dmap\LOCALS~1\Temp\JettyContext34026.tmp\_0002fjsp_0002fhello
_0002ejsphello_jsp_0.java:12: Package org.apache.jasper.runtime not found in
import.
import org.apache.jasper.runtime.*;
^
C:\DOCUME~1\dmap\LOCALS~1\Temp\JettyContext34026.tmp\_0002fjsp_0002fhello_00
02ejsphello_jsp_0.java:14: Class org.apache.jasper.JasperException not found
in import.
import org.apache.jasper.JasperException;
^
C:\DOCUME~1\dmap\LOCALS~1\Temp\JettyContext34026.tmp\_0002fjsp_0002fhello_00
02ejsphello_jsp_0.java:17: Superclass jsp.HttpJspBase of class
jsp._0002fjsp_0002fhello_0002ejsphello_jsp_0 not found.
public class _0002fjsp_0002fhello_0002ejsphello_jsp_0 extends HttpJspBase {
^
3 errors
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:249)
at
org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:448)
at
org.apache.jasper.servlet.JasperLoader12$1.run(JasperLoader12.java:160)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:156)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:419)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspSe
rvlet.java:151)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:163)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:307)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
com.mortbay.Jetty.Servlet.ServletHolder.handle(ServletHolder.java:488)
at
com.mortbay.Jetty.Servlet.ServletHandler.handle(ServletHandler.java:389)
at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:972)
at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:927)
at com.mortbay.HTTP.HttpServer.service(HttpServer.java:674)
at com.mortbay.HTTP.HttpConnection.service(HttpConnection.java:701)
at com.mortbay.HTTP.HttpConnection.handle(HttpConnection.java:864)
at
com.mortbay.HTTP.SocketListener.handleConnection(SocketListener.java:107)
at com.mortbay.Util.ThreadedServer.handle(ThreadedServer.java:294)
at
com.mortbay.Util.ThreadPool$PoolThreadRunnable.run(ThreadPool.java:613)
at java.lang.Thread.run(Thread.java:484)
getRootCause():
Any thoughts, or am I beyond help.
David
[JBoss-dev] Problems with getting EJB in JBoss
Hi all, I am not quite sure I fully understand what is going on. First I kept getting NOT BOUND exceptions. I found out that if I turn off the WebServer at port 8083, apparently my EJB wont deploy. I have no clue why this is. I would like to somehow start JBoss with NO ports open except the JNDI port that is required. I am clueless as to how this is done (as I am a newbie). The docs are a bit hard to understand. At any rate, somehow it appears I am finally able to get the JNDI lookup to my other maching, but the problem now is I am getting a java.lang.NoClassDefFoundError: org/jboss/security/SecurityAssociation in the web container. I would appreciate any help why this is happening. Thanks. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup and JBossMQ)
David Jencks wrote: Maybe it's my lack of imagination, but I'm having a hard time seeing how to combine JINI discovery/lookup with jmx mbean calls. I do wonder how much of what you are thinking of can be done with disciplined use of object names and mbean queries? Probably most. It's just levels of flexibility and dependency: either you say the exact service *instances* you need, or you specify the service *types* you need. For most cases the explicit way will probably work well, whereas it is possibly more selfmaintaining to only be dependent on service types. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is mail return acting peculiar?
Scott M Stark wrote: I haven't changed anything. Perhaps the sourceforge defaults have changed. Looking at the list admin page the default, and in sourceforge words strongly recommended, is to reply to the poster. All SF lists have been screwed up lately (all other SF projects I'm running too anyway). Use the mail admin to set back to list reply. Reply-to-poster is just annoying :-) /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458884 ] [EBn] LOCKING-WAITING (TRANSACTION)
Bugs item #458884, was opened at 2001-09-05 13:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=458884group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Buesing (buesing)
Assigned to: Nobody/Anonymous (nobody)
Summary: [EBn] LOCKING-WAITING (TRANSACTION)
Initial Comment:
I'm getting a LOCKING-WAITING (TRANSACTION) problem,
from EntityInstanceInterceptor, with concurrent access
to an entity bean from two threads.
The first thread classes a stateless session bean
method with a RequiresNew transaction and the second
thread calls the stateless session bean (different
instance) with a NotSupported transaction. Even
though 'NotSupported' is the transaction type for the
methods of the entity bean, the second thread is
locking until the first transaction is completed.
With the following pseudo code I will get this
transaction lock to occur, and I don't think it should
happen.
Consider the two classes:
SessionBean : SessionBn
// transaction type 'RequiresNew'
getEntityStateWithTransaction() {
EntityBnHome home = ... // lookup home.
EntityBn bean = home.findByPrimaryKey(new EntityBn
(1));
EntityBnState bean.getState();
try {
Thread.sleep(12);
} catch (Exception e) {
}
return state;
}
// transaction type 'NotSupported'
getEntityStateWithNoTransaction() {
EntityBnHome home = ... // lookup home.
EntityBn bean = home.findByPrimaryKey(new EntityBn
(1));
EntityBnState state = bean.getState();
return state;
}
EntityBean : EntityBn
// transaction type 'NotSupported' on all methods
getState();
My client runs two threads, each thread creates a
SessionBn, and the first thread calls
getEntityStateWithTransaction(), and the second thread
(starting 5 seconds later) calls
getEntityStateWithNoTransaction.
When I do this, the second thread will get a LOCKING-
WAITING (Transaction) message and wait until the first
thread is completed (and the transaction ends).
I will try to provide a test case, but I thought I
would post this right away, since maybe I'm messing
something up, or this is desired behavior.
I have the same problem in 2.2.1.
Thanks,
Neil
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=458884group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
