Re: [JBoss-dev] message redelivery MDB TX timeout with NotSupported

[Peter Antman]

On  9 Sep, Jason Dillon wrote:
  So, the first question is why does an MDB with NotSupported cause TX
  timeouts?

 Hiram is the one who did the transaction parts of the MDB, but I would
 geuss this is what is going on: An MDB is ALWAYS transacted (the receipt
 that is), the flags only determins under what TX context the bean is
 invoked. This mean there will allways be a transaction going on under
 the hood.
 
 Is that by design... that NotSupported still runs with a TX?

Yes, but remember. The receipt is under a transaction, but not the bean.

 
 I don't really have time to look into this more.  I think that changing the
 MDB to use a non-xa cf with NotSupported works but I am not 100% on
 that.  I hope that is the case at least =|

Thats true, it should work fine.

//Peter
 
  Second, why does a message get redelivered to my MDB, but does not have its
  getJMSRedelivered() set to true?

 That was fixed in JBossMQ during the time I implemented the Dead Letter
 Queue handler, which was commited after the RH stuff. There is a change
 note about it.
 
 Great.  Thanks.
 
 --jason
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development

-- 
Jobba hos oss: http://www.tim.se/weblab

Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems ArchitectWWW: http://www.tim.se
Email: [EMAIL PROTECTED]WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] message redelivery MDB TX timeout with NotSupported

[Jason Dillon]

  Hiram is the one who did the transaction parts of the MDB, but I would
  geuss this is what is going on: An MDB is ALWAYS transacted (the receipt
  that is), the flags only determins under what TX context the bean is
  invoked. This mean there will allways be a transaction going on under
  the hood.
 
  Is that by design... that NotSupported still runs with a TX?

 Yes, but remember. The receipt is under a transaction, but not the bean.

Ah, so it waits for onMessage() to complete.

Is the TX only for removing from the queue/topic?  Will this same TX be used
by component invocations done by the MDB in NotSupported?  Sorry, I am still
getting the hang of how EJB  JMS transactions really work.

Perhaps in this situation the receipt tx should be committed just prior to
calling onMessage()?

What are your thoughts about adding support for the MDB system to use an
optional dynamic policy to indicate if it should accept messages?  you know
instead of simply blindly taking messages from the queue/topic.  Perhaps
the dead letter support can be augmented to take a policy interceptor chain?

I would like to use MDB simplicity to process messages, but also make use of
JMS as a load balancer.  Right now I could simply have onMessage() throw
exceptions to indicate non-interest, but that is just plain crazy.

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] manual filtering

[Jeffrey C.H. Chang]

Is the manual build working?  I just did a clean check out on jboss-all and
tried jboss-all\manual\build docs-html, but it failed (see attached output
error and build.log).  Is it related the manual filtering problem you're
talking about?  I checked the file
D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl and
it's there.  Also, I tried build docs-html-plain and got the same error on
plain.xsl.  I'm new to the jboss development and didn't know much about
what the xml error in the build.log means.  Your help is appreciated.
Thanks,

--- Jeffrey



D:\projects\jboss-new\jboss-all\manualbuild docs-html
Calling ..\tools\bin\ant.bat docs-html
Buildfile: build.xml

init-buildlog:

init:
[moduleinfo] Project root: D:\projects\jboss-new\jboss-all
[moduleinfo]  Module root: D:\projects\jboss-new\jboss-all\manual

compile-stylesheets:

compile-docs:

compile-metadata:

compile:

docs-html-fancy:
[style] Transforming into
D:\projects\jboss-new\jboss-all\manual\output\html\fancy
[style] Transforming into
D:\projects\jboss-new\jboss-all\manual\output\html\fancy
[style] Loading stylesheet
D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl
[style] Error on line 14 of
file:///D:/projects/jboss-new/jboss-all/manual/output/stylesheets/fancy.xsl:
[style]   D
[style] Failed to read stylesheet
D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl
[style] Failed to process
D:\projects\jboss-new\jboss-all\manual\output\xdocs\jbossdocs.xml

BUILD FAILED

javax.xml.transform.TransformerConfigurationException: Failed to compile
stylesheet. 1 error detected.

Total time: 6 seconds

D:\projects\jboss-new\jboss-all\manual
D:\projects\jboss-new\jboss-all\manual
D:\projects\jboss-new\jboss-all\manual
D:\projects\jboss-new\jboss-all\manualcat build.log

init:
[moduleinfo]Project root: D:\projects\jboss-new\jboss-all
[moduleinfo] Module root: D:\projects\jboss-new\jboss-all\manual

compile-stylesheets:

compile-docs:

compile-metadata:

compile:

docs-html-fancy:
 [style]Transforming into
D:\projects\jboss-new\jboss-all\manual\output\html\fancy
 [style]Transforming into
D:\projects\jboss-new\jboss-all\manual\output\html\fancy
 [style]Loading stylesheet
D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl
 [style]Error on line 14 of
file:///D:/projects/jboss-new/jboss-all/manual/output/stylesheets/fancy.xsl:
 [style]  D
 [style]Failed to read stylesheet
D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl
 [style]Failed to process
D:\projects\jboss-new\jboss-all\manual\output\xdocs\jbossdocs.xml

BUILD FAILED

D:\projects\jboss-new\jboss-all\manual\build.xml:289:
javax.xml.transform.TransformerConfigurationException: Failed to compile
stylesheet. 1 error det
ected.
at
org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:351)
at
org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:179)
at org.apache.tools.ant.Task.perform(Task.java:217)
at org.apache.tools.ant.Target.execute(Target.java:164)
at org.apache.tools.ant.Target.performTasks(Target.java:182)
at org.apache.tools.ant.Project.executeTarget(Project.java:601)
at org.apache.tools.ant.Project.executeTargets(Project.java:560)
at org.apache.tools.ant.Main.runBuild(Main.java:454)
at org.apache.tools.ant.Main.start(Main.java:153)
at org.apache.tools.ant.Main.main(Main.java:176)
--- Nested Exception ---
javax.xml.transform.TransformerConfigurationException: Failed to compile
stylesheet. 1 error detected.
at
org.apache.tools.ant.taskdefs.XSLTProcess.configureLiaison(XSLTProcess.java:
465)
at
org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:339)
at
org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:179)
at org.apache.tools.ant.Task.perform(Task.java:217)
at org.apache.tools.ant.Target.execute(Target.java:164)
at org.apache.tools.ant.Target.performTasks(Target.java:182)
at org.apache.tools.ant.Project.executeTarget(Project.java:601)
at org.apache.tools.ant.Project.executeTargets(Project.java:560)
at org.apache.tools.ant.Main.runBuild(Main.java:454)
at org.apache.tools.ant.Main.start(Main.java:153)
at org.apache.tools.ant.Main.main(Main.java:176)
--- Nested Exception ---

END




 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf
 Of Jason Dillon
 Sent: Wednesday, September 05, 2001 6:23 PM
 To: Scott M Stark
 Cc: JBoss Dev
 Subject: 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.
  

RE: [JBoss-dev] manual filtering

[Jason Dillon]

Looks like that URL spec is not happy.  you can change the
oasis.docbook.xsl.root property in ../build/local.properties, to something
win32 compatible.

Can someone explain to my what the file:// semantics for a win32 path spec
is?

I am almost done testing some changes to the build system (the last ones for
a while I hope), which will have better support for handling this (and a few
other issues).

In the mean time, you can simply change the property to be something that
style won't freak out about.

--jason


On Mon, 10 Sep 2001, Jeffrey C.H. Chang wrote:


 Is the manual build working?  I just did a clean check out on jboss-all and
 tried jboss-all\manual\build docs-html, but it failed (see attached output
 error and build.log).  Is it related the manual filtering problem you're
 talking about?  I checked the file
 D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl and
 it's there.  Also, I tried build docs-html-plain and got the same error on
 plain.xsl.  I'm new to the jboss development and didn't know much about
 what the xml error in the build.log means.  Your help is appreciated.
 Thanks,

 --- Jeffrey



 D:\projects\jboss-new\jboss-all\manualbuild docs-html
 Calling ..\tools\bin\ant.bat docs-html
 Buildfile: build.xml

 init-buildlog:

 init:
 [moduleinfo] Project root: D:\projects\jboss-new\jboss-all
 [moduleinfo]  Module root: D:\projects\jboss-new\jboss-all\manual

 compile-stylesheets:

 compile-docs:

 compile-metadata:

 compile:

 docs-html-fancy:
 [style] Transforming into
 D:\projects\jboss-new\jboss-all\manual\output\html\fancy
 [style] Transforming into
 D:\projects\jboss-new\jboss-all\manual\output\html\fancy
 [style] Loading stylesheet
 D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl
 [style] Error on line 14 of
 file:///D:/projects/jboss-new/jboss-all/manual/output/stylesheets/fancy.xsl:
 [style]   D
 [style] Failed to read stylesheet
 D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl
 [style] Failed to process
 D:\projects\jboss-new\jboss-all\manual\output\xdocs\jbossdocs.xml

 BUILD FAILED

 javax.xml.transform.TransformerConfigurationException: Failed to compile
 stylesheet. 1 error detected.

 Total time: 6 seconds

 D:\projects\jboss-new\jboss-all\manual
 D:\projects\jboss-new\jboss-all\manual
 D:\projects\jboss-new\jboss-all\manual
 D:\projects\jboss-new\jboss-all\manualcat build.log

 init:
 [moduleinfo]Project root: D:\projects\jboss-new\jboss-all
 [moduleinfo] Module root: D:\projects\jboss-new\jboss-all\manual

 compile-stylesheets:

 compile-docs:

 compile-metadata:

 compile:

 docs-html-fancy:
  [style]Transforming into
 D:\projects\jboss-new\jboss-all\manual\output\html\fancy
  [style]Transforming into
 D:\projects\jboss-new\jboss-all\manual\output\html\fancy
  [style]Loading stylesheet
 D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl
  [style]Error on line 14 of
 file:///D:/projects/jboss-new/jboss-all/manual/output/stylesheets/fancy.xsl:
  [style]  D
  [style]Failed to read stylesheet
 D:\projects\jboss-new\jboss-all\manual\output\stylesheets\fancy.xsl
  [style]Failed to process
 D:\projects\jboss-new\jboss-all\manual\output\xdocs\jbossdocs.xml

 BUILD FAILED

 D:\projects\jboss-new\jboss-all\manual\build.xml:289:
 javax.xml.transform.TransformerConfigurationException: Failed to compile
 stylesheet. 1 error det
 ected.
 at
 org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:351)
 at
 org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:179)
 at org.apache.tools.ant.Task.perform(Task.java:217)
 at org.apache.tools.ant.Target.execute(Target.java:164)
 at org.apache.tools.ant.Target.performTasks(Target.java:182)
 at org.apache.tools.ant.Project.executeTarget(Project.java:601)
 at org.apache.tools.ant.Project.executeTargets(Project.java:560)
 at org.apache.tools.ant.Main.runBuild(Main.java:454)
 at org.apache.tools.ant.Main.start(Main.java:153)
 at org.apache.tools.ant.Main.main(Main.java:176)
 --- Nested Exception ---
 javax.xml.transform.TransformerConfigurationException: Failed to compile
 stylesheet. 1 error detected.
 at
 org.apache.tools.ant.taskdefs.XSLTProcess.configureLiaison(XSLTProcess.java:
 465)
 at
 org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:339)
 at
 org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:179)
 at org.apache.tools.ant.Task.perform(Task.java:217)
 at org.apache.tools.ant.Target.execute(Target.java:164)
 at org.apache.tools.ant.Target.performTasks(Target.java:182)
 at org.apache.tools.ant.Project.executeTarget(Project.java:601)
 at org.apache.tools.ant.Project.executeTargets(Project.java:560)
 at org.apache.tools.ant.Main.runBuild(Main.java:454)
 at 

[JBoss-dev] Jboss 2.4.1

[Vincent Harcq]

Hi,
Under branch 2.4.1.
jboss-j2ee.jar in src/client and src/lib are not the same, the one in client
does not contain EJB 2.0 classes.
Regards.
Vincent.


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] exposing boot sequence richer xml config

[Jason Dillon]

I thought about it this weekend some more, and worked on an example xml
configuration too.  This is a spin off of the Jetty config, but I think most
uses will not require some of the advanced get/new stuff (which leaves you
mostly with what we have no, only more flexibly).

This is all/mostly made up at the moment...

 * * *

?xml version=1.0 encoding=UTF-8?
!DOCTYPE jboss-server

jboss-server

  !--
 | set some system properties, these should really be defaults, if use
 | specified on command line -Djboss.home=xxx then ${jboss.home} must
 | must equal xxx, no the value of ${jboss.boot}.
   --

  !-- jboss.boot will be set by Main, based on where run.jar was --
  property name=jboss.home${jboss.boot}/property
  property name=jboss.lib${jboss.home}/lib/property
  property name=jboss.conf${jboss.home}/lib/property

  !-- these are for uses where a local file system is required --
  property name=jboss.local${user.home}/property
  property name=jboss.tmp${jboss.local}/tmp/property
  property name=jboss.var${jboss.local}/var/property

  !--
 | bootstrap sequencing and configuration.  this contains the definitions
 | of the core system services.
 |
 | if omitted, then a default is pulled from the resource
 | default-server.xml (METAINF or org/jboss/system).
 |
 | domain param will default all domain'able elements to this value if
 | the domain attribute is not specified. (save for services and domain tags).
   --

  bootstrap domain=JBOSS-SYSTEM

 !--
| Setup the mbean loader, by exposing the MBeanClassLoader, we can
| have flebible control over the classes available to services from the
| same configuration.  Or a classpath elem. could contain other mbean calls?
  --

 mbean name=MBeanLoader class=org.jboss.system.MBeanLoader
   set name=classpath
 ${jboss.lib}/jboss-spine.jar,
 ${jboss.lib}/log4j.jar
   /set
 /mbean

 !-- Use this MBean loader for botting --
 mbeanloader name=MBeanLoader

   !-- get logging up and running --
   mbean name=Logging class=org.jboss.system.Logging
 !-- override the default logger type for log4j --
 set name=LoggerFactoryType
   new class=org.jboss.log.log4j.CategoryLoggerFactory

 !-- override the default configuration file --
 set name=ConfigURL${jboss.conf}/log4j.xml/set

 !-- override the default refresh interval --
 set name=RefreshInterval600/set
   /new
 /set
   /mbean

   !-- Logging is now functional --

   !--
  | next startup the library manager, with handle getting classes
  |
  | provides a robust mechanism for getting class libraries, may boot
  | strap higher functionality after establishing link to BaseURL.
--
   mbean name=LibraryManager
  class=org.jboss.system.LibraryManager
 set name=BaseURL${jboss.lib}/set
 set name=StateDir${jboss.var}/libcache/set
   /mbean

   !--
  | Manage security.
--
   mbean name=SecurityManager class=org.jboss.system.SecurityManager
 !-- who knows --
 set name=Passwordhi/set
   /mbean

   !--
  | this is shutdown and info
  |
  | provides access to server lifecycle events, perhaps even a meeting place
  | for system events?
--
   mbean name=SystemManager class=org.jboss.system.SystemManager

 !--
| do not System.exit() when asked to shutdown, in case we are embeded,
| should still go through shutdown hooks, need to manage them in tandem
| with the runtime.
  --

 set name=ForceExitfalse/set
   /mbean

   !--
  | setup the service controller and deployer
  |
  | this will take over with all other loading and provide a richer
  | language interface.
--
   mbean name=ServiceController
  class=org.jboss.system.ServiceController/
   mbean name=ServiceDeployer
  class=org.jboss.system.ServiceDeployer/

 /mbeanloader

 !-- if you got to here we are good, else an error will be thrown --
  /bootstrap

  !--
 | service configuration
 |
 | services which are not required to bootstrap, such as user services
 | are defined here.
   --

  services domain=MyDefaultDomain

!-- use of domain element for bean grouping --
domain name=my.domain

  !--
 | the service element is used for mbeans that have lifecycle methods
 | exposed.
   --

  service name=mybean class=MyBeanClass
set name=MyAttributesome.value/set
  /service
/domain

!-- use of domain attribute --
service name=mybean domain=my.other.domain class=MyBeanClass

  !--
 | Get the service context, then modify the lifecycle map
 |
 | all services bound are 

Re: [JBoss-dev] exposing boot sequence richer xml config

[Nick Betteridge]

Couldn't you also define classloaders here for the Security Manager?

Jason Dillon wrote:
 
 I thought about it this weekend some more, and worked on an example xml
 configuration too.  This is a spin off of the Jetty config, but I think most
 uses will not require some of the advanced get/new stuff (which leaves you
 mostly with what we have no, only more flexibly).
 
 This is all/mostly made up at the moment...
 
  * * *
 
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE jboss-server
 
 jboss-server
 
   !--
  | set some system properties, these should really be defaults, if use
  | specified on command line -Djboss.home=xxx then ${jboss.home} must
  | must equal xxx, no the value of ${jboss.boot}.
--
 
   !-- jboss.boot will be set by Main, based on where run.jar was --
   property name=jboss.home${jboss.boot}/property
   property name=jboss.lib${jboss.home}/lib/property
   property name=jboss.conf${jboss.home}/lib/property
 
   !-- these are for uses where a local file system is required --
   property name=jboss.local${user.home}/property
   property name=jboss.tmp${jboss.local}/tmp/property
   property name=jboss.var${jboss.local}/var/property
 
   !--
  | bootstrap sequencing and configuration.  this contains the definitions
  | of the core system services.
  |
  | if omitted, then a default is pulled from the resource
  | default-server.xml (METAINF or org/jboss/system).
  |
  | domain param will default all domain'able elements to this value if
  | the domain attribute is not specified. (save for services and domain tags).
--
 
   bootstrap domain=JBOSS-SYSTEM
 
  !--
 | Setup the mbean loader, by exposing the MBeanClassLoader, we can
 | have flebible control over the classes available to services from the
 | same configuration.  Or a classpath elem. could contain other mbean calls?
   --
 
  mbean name=MBeanLoader class=org.jboss.system.MBeanLoader
set name=classpath
  ${jboss.lib}/jboss-spine.jar,
  ${jboss.lib}/log4j.jar
/set
  /mbean
 
  !-- Use this MBean loader for botting --
  mbeanloader name=MBeanLoader
 
!-- get logging up and running --
mbean name=Logging class=org.jboss.system.Logging
  !-- override the default logger type for log4j --
  set name=LoggerFactoryType
new class=org.jboss.log.log4j.CategoryLoggerFactory
 
  !-- override the default configuration file --
  set name=ConfigURL${jboss.conf}/log4j.xml/set
 
  !-- override the default refresh interval --
  set name=RefreshInterval600/set
/new
  /set
/mbean
 
!-- Logging is now functional --
 
!--
   | next startup the library manager, with handle getting classes
   |
   | provides a robust mechanism for getting class libraries, may boot
   | strap higher functionality after establishing link to BaseURL.
 --
mbean name=LibraryManager
   class=org.jboss.system.LibraryManager
  set name=BaseURL${jboss.lib}/set
  set name=StateDir${jboss.var}/libcache/set
/mbean
 
!--
   | Manage security.
 --
mbean name=SecurityManager class=org.jboss.system.SecurityManager
  !-- who knows --
  set name=Passwordhi/set
/mbean
 
!--
   | this is shutdown and info
   |
   | provides access to server lifecycle events, perhaps even a meeting place
   | for system events?
 --
mbean name=SystemManager class=org.jboss.system.SystemManager
 
  !--
 | do not System.exit() when asked to shutdown, in case we are embeded,
 | should still go through shutdown hooks, need to manage them in tandem
 | with the runtime.
   --
 
  set name=ForceExitfalse/set
/mbean
 
!--
   | setup the service controller and deployer
   |
   | this will take over with all other loading and provide a richer
   | language interface.
 --
mbean name=ServiceController
   class=org.jboss.system.ServiceController/
mbean name=ServiceDeployer
   class=org.jboss.system.ServiceDeployer/
 
  /mbeanloader
 
  !-- if you got to here we are good, else an error will be thrown --
   /bootstrap
 
   !--
  | service configuration
  |
  | services which are not required to bootstrap, such as user services
  | are defined here.
--
 
   services domain=MyDefaultDomain
 
 !-- use of domain element for bean grouping --
 domain name=my.domain
 
   !--
  | the service element is used for mbeans that have lifecycle methods
  | exposed.
--
 
   service name=mybean class=MyBeanClass
 set name=MyAttributesome.value/set
   /service
 

Re: [JBoss-dev] message redelivery MDB TX timeout with NotSupport ed

[Peter Antman]

On 10 Sep, Jason Dillon wrote:
  Hiram is the one who did the transaction parts of the MDB, but I would
  geuss this is what is going on: An MDB is ALWAYS transacted (the receipt
  that is), the flags only determins under what TX context the bean is
  invoked. This mean there will allways be a transaction going on under
  the hood.
 
  Is that by design... that NotSupported still runs with a TX?

 Yes, but remember. The receipt is under a transaction, but not the bean.
 
 Ah, so it waits for onMessage() to complete.
 
 Is the TX only for removing from the queue/topic?  Will this same TX be used
 by component invocations done by the MDB in NotSupported?  Sorry, I am still
 getting the hang of how EJB  JMS transactions really work.

First: StdServerSession.run() is the place to look in. Thats where the
meat of the invokation is done.


Here is part of the flow:

1. Connection consumer get ServerSession
2. Invokes run()
3. Transaction is started and enlisted if there was a XA cf.
4. ServerSession invokes run on JMS session.
5. JMS session calles JMSContanerInvoker.
6. Container invoker calls interceptor chain
7. TX interceptor handles TX, if Required (CMT) the bean is invoked with
   the TX started in 3, if NotSuported the transaction is suspended
   during the call to the MDB and resumed afterwards.

8. Bean is finally called.
...Trickled back though the chain
9. the run() method finnished by committing the transaction.

 
 Perhaps in this situation the receipt tx should be committed just prior to
 calling onMessage()?

I really do not know if that is even possible, but even if it is it is
risky. You might say the the spec says that message receipt is out of
controll of the MDB with NotSuported or BMT and therefore an ack
alaready at message receipt at a hight level would be ok.

On the other hand, I would say, that what the contract guarantes is that
any container failour should be treated with and not result in an acked
message receipt. If the we ack early in the chain, we certainly expose
our self of container failours that will not leed to a non acked
receipt.

 
 What are your thoughts about adding support for the MDB system to use an
 optional dynamic policy to indicate if it should accept messages?  you know
 instead of simply blindly taking messages from the queue/topic.  Perhaps
 the dead letter support can be augmented to take a policy interceptor chain?
 

That might be an idea, but in generall, all this have to lie within the
JMS provider. Say the MDB container might decide not allow a new
message, and did not ack it, if this message really would find its way
into another MDB somewhere is really up to the JMS provider to decide.
As far as last we discussed this, this behavour is not implemented in
JBossMQ.


 I would like to use MDB simplicity to process messages, but also make use of
 JMS as a load balancer.  Right now I could simply have onMessage() throw
 exceptions to indicate non-interest, but that is just plain crazy.

No you could not, since JBossMQ has alreadt delivered the message to the
local consumer and will try and try again to deliver it to that one (as
far as I know). As far as I can see it your load balancing will never be
better than the balancing algorithm the JMS provider uses to publish
queue messaged to the queue subscribers.

Basically: its up to the JMS provider.

However: if you are willing to roll your own JMSContainerInvoker you
could probably use another aproach. Write an invoker that only handles
one message a time and does a receive. Something like this.

for(;;) {
Message m = messageConsumer.receive();
onMessage(m);
}


You could overide typically init and start to implement your special
code


Well, maybe that idea stinks, or maybe we could build some extended
functionality into the vanilla JMSContainerInvoker. I really do not
know, but I think it would get you your wanted behaviour.

//Peter



 
 --jason
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development

-- 
Jobba hos oss: http://www.tim.se/weblab

Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems ArchitectWWW: http://www.tim.se
Email: [EMAIL PROTECTED]WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/bin run.sh

[Chris Kimpton]

  User: kimptoc 
  Date: 01/09/10 05:40:33

  Modified:src/bin  run.sh
  Log:
  fixed bug with regard to setting the -server flag, it was never being set before
  
  Revision  ChangesPath
  1.29  +2 -2  jboss/src/bin/run.sh
  
  Index: run.sh
  ===
  RCS file: /cvsroot/jboss/jboss/src/bin/run.sh,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- run.sh2001/09/07 22:30:47 1.28
  +++ run.sh2001/09/10 12:40:33 1.29
  @@ -5,7 +5,7 @@
   ##  ##
   ### == ###
   
  -### $Id: run.sh,v 1.28 2001/09/07 22:30:47 starksm Exp $ ###
  +### $Id: run.sh,v 1.29 2001/09/10 12:40:33 kimptoc Exp $ ###
   
   DIRNAME=`dirname $0`
   PROGNAME=`basename $0`
  @@ -44,7 +44,7 @@
   HAS_HOTSPOT=`$JAVA -version 21 | $GREP HotSpot`
   
   # If JAVA_OPTS is not set and the JVM is HOTSPOT enabled, then the server mode
  -if [ x$JAVA_OPTS = x -a x$HOTSPOT != x ]; then
  +if [ x$JAVA_OPTS = x -a x$HAS_HOTSPOT != x ]; then
   JAVA_OPTS=-server
   fi
   
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] message redelivery MDB TX timeout with NotSupport ed

[Hiram Chirino]

Hi I thought of an Idea that should fix Jason's problem while not chaning 
the current MDB invoker too much.  What we have to do is get rid of that 
ugly timeout.  So when MDB TX is NotSupported, lets not elist the TX with 
the TM since he sill timeout the transaction.  Lets just manually 
commit/rollback the TX via the sessions's XAResource.

What do you think???

Regards,
Hiram

From: Peter Antman [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] message redelivery  MDB TX timeout with 
NotSupport  ed
Date: Mon, 10 Sep 2001 13:17:23 +0200 (CEST)

On 10 Sep, Jason Dillon wrote:
   Hiram is the one who did the transaction parts of the MDB, but I 
would
   geuss this is what is going on: An MDB is ALWAYS transacted (the 
receipt
   that is), the flags only determins under what TX context the bean is
   invoked. This mean there will allways be a transaction going on 
under
   the hood.
  
   Is that by design... that NotSupported still runs with a TX?
 
  Yes, but remember. The receipt is under a transaction, but not the 
bean.
 
  Ah, so it waits for onMessage() to complete.
 
  Is the TX only for removing from the queue/topic?  Will this same TX be 
used
  by component invocations done by the MDB in NotSupported?  Sorry, I am 
still
  getting the hang of how EJB  JMS transactions really work.

First: StdServerSession.run() is the place to look in. Thats where the
meat of the invokation is done.


Here is part of the flow:

1. Connection consumer get ServerSession
2. Invokes run()
3. Transaction is started and enlisted if there was a XA cf.
4. ServerSession invokes run on JMS session.
5. JMS session calles JMSContanerInvoker.
6. Container invoker calls interceptor chain
7. TX interceptor handles TX, if Required (CMT) the bean is invoked with
the TX started in 3, if NotSuported the transaction is suspended
during the call to the MDB and resumed afterwards.

8. Bean is finally called.
...Trickled back though the chain
9. the run() method finnished by committing the transaction.

 
  Perhaps in this situation the receipt tx should be committed just prior 
to
  calling onMessage()?

I really do not know if that is even possible, but even if it is it is
risky. You might say the the spec says that message receipt is out of
controll of the MDB with NotSuported or BMT and therefore an ack
alaready at message receipt at a hight level would be ok.

On the other hand, I would say, that what the contract guarantes is that
any container failour should be treated with and not result in an acked
message receipt. If the we ack early in the chain, we certainly expose
our self of container failours that will not leed to a non acked
receipt.

 
  What are your thoughts about adding support for the MDB system to use an
  optional dynamic policy to indicate if it should accept messages?  you 
know
  instead of simply blindly taking messages from the queue/topic.  Perhaps
  the dead letter support can be augmented to take a policy interceptor 
chain?
 

That might be an idea, but in generall, all this have to lie within the
JMS provider. Say the MDB container might decide not allow a new
message, and did not ack it, if this message really would find its way
into another MDB somewhere is really up to the JMS provider to decide.
As far as last we discussed this, this behavour is not implemented in
JBossMQ.


  I would like to use MDB simplicity to process messages, but also make 
use of
  JMS as a load balancer.  Right now I could simply have onMessage() throw
  exceptions to indicate non-interest, but that is just plain crazy.

No you could not, since JBossMQ has alreadt delivered the message to the
local consumer and will try and try again to deliver it to that one (as
far as I know). As far as I can see it your load balancing will never be
better than the balancing algorithm the JMS provider uses to publish
queue messaged to the queue subscribers.

Basically: its up to the JMS provider.

However: if you are willing to roll your own JMSContainerInvoker you
could probably use another aproach. Write an invoker that only handles
one message a time and does a receive. Something like this.

for(;;) {
   Message m = messageConsumer.receive();
   onMessage(m);
}


You could overide typically init and start to implement your special
code


Well, maybe that idea stinks, or maybe we could build some extended
functionality into the vanilla JMSContainerInvoker. I really do not
know, but I think it would get you your wanted behaviour.

//Peter



 
  --jason
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development

--
Jobba hos oss: http://www.tim.se/weblab

Peter AntmanTechnology in Media, Box 34105 100 26 Stockholm
Systems Architect   WWW: http://www.tim.se
Email: [EMAIL PROTECTED]   

Re: [JBoss-dev] message redelivery MDB TX timeout with NotSupport ed

[Peter Antman]

On 10 Sep, Hiram Chirino wrote:
 
 Hi I thought of an Idea that should fix Jason's problem while not chaning 
 the current MDB invoker too much.  What we have to do is get rid of that 
 ugly timeout.  So when MDB TX is NotSupported, lets not elist the TX with 
 the TM since he sill timeout the transaction.  Lets just manually 
 commit/rollback the TX via the sessions's XAResource.
 
 What do you think???

Yupp, that might be it. Would have to lookinto what info the
ServerSession and ServerSession pool has about the transaction
atributes. What could perhaps be used (which we did before) was to use
the ACK mode in ServerSessionPool. This will be CLIENT_ACKNOWLEDGE_MODE
when and only when we have a TX Required.

//Peter
 
 Regards,
 Hiram
 
From: Peter Antman [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] message redelivery  MDB TX timeout with 
NotSupport  ed
Date: Mon, 10 Sep 2001 13:17:23 +0200 (CEST)

On 10 Sep, Jason Dillon wrote:
   Hiram is the one who did the transaction parts of the MDB, but I 
would
   geuss this is what is going on: An MDB is ALWAYS transacted (the 
receipt
   that is), the flags only determins under what TX context the bean is
   invoked. This mean there will allways be a transaction going on 
under
   the hood.
  
   Is that by design... that NotSupported still runs with a TX?
 
  Yes, but remember. The receipt is under a transaction, but not the 
bean.
 
  Ah, so it waits for onMessage() to complete.
 
  Is the TX only for removing from the queue/topic?  Will this same TX be 
used
  by component invocations done by the MDB in NotSupported?  Sorry, I am 
still
  getting the hang of how EJB  JMS transactions really work.

First: StdServerSession.run() is the place to look in. Thats where the
meat of the invokation is done.


Here is part of the flow:

1. Connection consumer get ServerSession
2. Invokes run()
3. Transaction is started and enlisted if there was a XA cf.
4. ServerSession invokes run on JMS session.
5. JMS session calles JMSContanerInvoker.
6. Container invoker calls interceptor chain
7. TX interceptor handles TX, if Required (CMT) the bean is invoked with
the TX started in 3, if NotSuported the transaction is suspended
during the call to the MDB and resumed afterwards.

8. Bean is finally called.
...Trickled back though the chain
9. the run() method finnished by committing the transaction.

 
  Perhaps in this situation the receipt tx should be committed just prior 
to
  calling onMessage()?

I really do not know if that is even possible, but even if it is it is
risky. You might say the the spec says that message receipt is out of
controll of the MDB with NotSuported or BMT and therefore an ack
alaready at message receipt at a hight level would be ok.

On the other hand, I would say, that what the contract guarantes is that
any container failour should be treated with and not result in an acked
message receipt. If the we ack early in the chain, we certainly expose
our self of container failours that will not leed to a non acked
receipt.

 
  What are your thoughts about adding support for the MDB system to use an
  optional dynamic policy to indicate if it should accept messages?  you 
know
  instead of simply blindly taking messages from the queue/topic.  Perhaps
  the dead letter support can be augmented to take a policy interceptor 
chain?
 

That might be an idea, but in generall, all this have to lie within the
JMS provider. Say the MDB container might decide not allow a new
message, and did not ack it, if this message really would find its way
into another MDB somewhere is really up to the JMS provider to decide.
As far as last we discussed this, this behavour is not implemented in
JBossMQ.


  I would like to use MDB simplicity to process messages, but also make 
use of
  JMS as a load balancer.  Right now I could simply have onMessage() throw
  exceptions to indicate non-interest, but that is just plain crazy.

No you could not, since JBossMQ has alreadt delivered the message to the
local consumer and will try and try again to deliver it to that one (as
far as I know). As far as I can see it your load balancing will never be
better than the balancing algorithm the JMS provider uses to publish
queue messaged to the queue subscribers.

Basically: its up to the JMS provider.

However: if you are willing to roll your own JMSContainerInvoker you
could probably use another aproach. Write an invoker that only handles
one message a time and does a receive. Something like this.

for(;;) {
  Message m = messageConsumer.receive();
  onMessage(m);
}


You could overide typically init and start to implement your special
code


Well, maybe that idea stinks, or maybe we could build some extended
functionality into the vanilla JMSContainerInvoker. I really do not
know, but I think it would get you your wanted behaviour.

//Peter



 
  --jason
 
 
  ___
  

Re: [JBoss-dev] exposing boot sequence richer xml config

[David Jencks]

Jason,

I'm still confused about what you are trying to accomplish here.  I would
really appreciate it if you could take a few minutes and write down,
without specifying a notation, the sequence of events you are trying to
control and the variation points along that sequence.

for instance (made up quickly),

Admin logs into server#57 with ssh. Server#57 has jboss-spine.jar on it.

Admin starts jboss using run.sh
--variation points: location of log4j config, location of
jboss-service.xml, location of deploy/lib, may be starting an app that has
jboss embedded.

jboss spine starts up
 starts log4j
 starts MBeanClassLoader
 starts info
 starts shutdown
 starts ServiceController
 starts ServiceDeployer
 processes jboss-service.xml
 autodeploys sar and *-service.xml packages from deploy/lib
--variation points: shutdown not necessary if started embedded.

...

If you could do this I would find it _much_ easier to think about how to
implement the functionality.

thanks
david jencks

On 2001.09.10 04:44:54 -0400 Jason Dillon wrote:
 I thought about it this weekend some more, and worked on an example xml
 configuration too.  This is a spin off of the Jetty config, but I think
 most
 uses will not require some of the advanced get/new stuff (which leaves
 you
 mostly with what we have no, only more flexibly).
 
 This is all/mostly made up at the moment...
 
  * * *
 
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE jboss-server
 
 jboss-server
 
   !--
  | set some system properties, these should really be defaults, if
 use
  | specified on command line -Djboss.home=xxx then ${jboss.home} must
  | must equal xxx, no the value of ${jboss.boot}.
--
 
   !-- jboss.boot will be set by Main, based on where run.jar was --
   property name=jboss.home${jboss.boot}/property
   property name=jboss.lib${jboss.home}/lib/property
   property name=jboss.conf${jboss.home}/lib/property
 
   !-- these are for uses where a local file system is required --
   property name=jboss.local${user.home}/property
   property name=jboss.tmp${jboss.local}/tmp/property
   property name=jboss.var${jboss.local}/var/property
 
   !--
  | bootstrap sequencing and configuration.  this contains the
 definitions
  | of the core system services.
  |
  | if omitted, then a default is pulled from the resource
  | default-server.xml (METAINF or org/jboss/system).
  |
  | domain param will default all domain'able elements to this value
 if
  | the domain attribute is not specified. (save for services and
 domain tags).
--
 
   bootstrap domain=JBOSS-SYSTEM
 
  !--
 | Setup the mbean loader, by exposing the MBeanClassLoader, we
 can
 | have flebible control over the classes available to services
 from the
 | same configuration.  Or a classpath elem. could contain other
 mbean calls?
   --
 
  mbean name=MBeanLoader class=org.jboss.system.MBeanLoader
set name=classpath
  ${jboss.lib}/jboss-spine.jar,
  ${jboss.lib}/log4j.jar
/set
  /mbean
 
  !-- Use this MBean loader for botting --
  mbeanloader name=MBeanLoader
 
!-- get logging up and running --
mbean name=Logging class=org.jboss.system.Logging
  !-- override the default logger type for log4j --
  set name=LoggerFactoryType
new class=org.jboss.log.log4j.CategoryLoggerFactory
 
  !-- override the default configuration file --
  set name=ConfigURL${jboss.conf}/log4j.xml/set
 
  !-- override the default refresh interval --
  set name=RefreshInterval600/set
/new
  /set
/mbean
 
!-- Logging is now functional --
 
!--
   | next startup the library manager, with handle getting classes
   |
   | provides a robust mechanism for getting class libraries, may
 boot
   | strap higher functionality after establishing link to
 BaseURL.
 --
mbean name=LibraryManager
 class=org.jboss.system.LibraryManager
  set name=BaseURL${jboss.lib}/set
  set name=StateDir${jboss.var}/libcache/set
/mbean
 
!--
   | Manage security.
 --
mbean name=SecurityManager
 class=org.jboss.system.SecurityManager
  !-- who knows --
  set name=Passwordhi/set
/mbean
 
!--
   | this is shutdown and info
   |
   | provides access to server lifecycle events, perhaps even a
 meeting place
   | for system events?
 --
mbean name=SystemManager class=org.jboss.system.SystemManager
 
  !--
 | do not System.exit() when asked to shutdown, in case we are
 embeded,
 | should still go through shutdown hooks, need to manage them
 in tandem
 | with the runtime.
   --
 
  set name=ForceExitfalse/set
/mbean
 
!--
   | setup the 

RE: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?

[Bill Burke]

Rickard,

We were hoping you would respond to this email.  I'll have to answer for
Sacha, since he's in London.  What he's really getting at is, Is there
really any meat behind JINI?  JavaGroups(JG) is definately pretty meaty and
provides solid, reliable communications protocols.  Read on

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of
 Rickard Öberg
 Sent: Monday, September 10, 2001 2:20 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?


 Sacha Labourey wrote:
  Nevertheless, as you probably know, when doing clustering we
 also need some
  advanced communication semantics. We need to be able to know
 which message
  has been received by which member in which order (for example).
 A cluster
  where invocations cannot be received in the same order by each
 node, when
  you do not know which node has received which message, ... is not a very
  usefull cluster IMHO.

 You are making way too many assumptions about how to implement the
 cluster here. There is no inherent need for what you describe.


#1, Sacha is not making assumptions.  He has been working on clustering a
few months now and has checked in an implementation written on top of JG for
HA SLSBs.  He and I are currently working on expanding and re-designing this
implementation, so we both have put in much thought on how the cluster
should work.

   And this is JavaGroups job. JG provides memberhip
  protocol, state transfer protocol, group views, group
 communication, ... JG
  also provides a kind of discovery ;) : you create a group with
 a particular
  name, and you then are able to use extended communication
 semantic in the
  group, get state transfer events, membership events, ...

 There is a lot of complexity inherent in what you describe above. I
 doubt that most of that will be useful. And I'm assuming we're talking
 about clustering the EJB container here. For the JMS stuff the above
 will be more interesting.


1. Membership events are very useful.  With JG, a node can join a cluster
and discover the other nodes in the cluster and populate itself with any
distributed state from other nodes.  Also, nodes can register for change of
membership events.  This is extremely useful for replicated RMI proxies that
must purge or refresh their lists of viable targets.

2. State transfer and message ordering protocols are extremely important
when your cluster has distributed state that must be kept synchronized.
Examples of distributed state are JNDI (we have a Highly Available JNDI
implementation), configuration data, HA-SFSBs.  (Also, in our cluster
implementation we also have a ReplicantManager that manages replicated
things like RMI proxies.  This is also plugged into the state-transfer
protocol).  JG has a decent, reliable, state transfer protocol, please read
the following
http://www.javagroups.com/user/node142.html#StateTransferEventsFig

Sacha and I think we have designed a framework in which other group
communication packages could be plugged in.  Maybe JINI is one of these
protocols.  Does it provide:

1. Group discovery
2. Ability to register for change of membership events
3. Reliable state-transfer protocol
4. Ability to send messages(RPCs) to one, some, or all members of a group.

Or even better, as Jason Dillon points out, does it provide an abstracted
interface with the above features that JG can plug into?  Sacha and I have
developed our own abstraction interface, but maybe JINI provides a better
one.  I personally know jack squat about JINI and should really read up on
it if it really is a viable solution. Or is it just vaporware, or
prototypeware.

Bill



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] log4j switchover - anyone working on this?

[Chris Kimpton]

Hi,

I'd like to fix the org.jboss.logging deprecation messages - which
means replacing the logging with log4j calls...

So - is anyone doing this already?

I plan to look for code that has the correct logging and doing
like-wise - so any recommendations?

I am assuming that there is no reason for not fully switching over to
log4j...

Regards,
Chris

=
Need somewhere to Live in London - http://freeflats.com

__
Do You Yahoo!?
Get email alerts  NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss-j2ee/src/build build.xml

[Scott M Stark]

  User: starksm 
  Date: 01/09/10 09:36:32

  Modified:src/build Tag: Branch_2_4 build.xml
  Log:
  Add install and src-install target to build the j2ee jars into jboss dist
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.8.2.1   +12 -0 jboss-j2ee/src/build/Attic/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/jboss-j2ee/src/build/Attic/build.xml,v
  retrieving revision 1.8
  retrieving revision 1.8.2.1
  diff -u -r1.8 -r1.8.2.1
  --- build.xml 2001/06/04 15:57:17 1.8
  +++ build.xml 2001/09/10 16:36:31 1.8.2.1
  @@ -33,6 +33,7 @@
   property name=build.javadocs.dir value=${build.dir}/docs/api/
   property name=dist.dir value=dist/
   property name=external.dir value=${dist.dir}/external/
  +property name=jboss.dist value=../jboss/dist /
   
   property name=classpath 
value=${build.classes.dir};${src.lib.dir}/jaas.jar/
   property name=packages 
value=javax.ejb,javax.ejb.spi,javax.transaction,javax.resource,javax.resource.spi,javax.resource.spi.security,javax.resource.cci,javax.jms,javax.sql/
  @@ -89,6 +90,17 @@
basedir=${build.classes.dir}
includes=${j2ee-packages.expr}
   /
  +  /target
  +
  +  target name=install depends=jar
  +copy file=${external.dir}/jboss-j2ee.jar todir=${jboss.dist}/client /
  +copy file=${external.dir}/jboss-jdbc_ext.jar todir=${jboss.dist}/lib /
  +copy file=${external.dir}/jboss-j2ee.jar todir=${jboss.dist}/lib/ext /
  +  /target
  +  target name=src-install depends=jar
  +copy file=${external.dir}/jboss-j2ee.jar todir=${jboss.dist}/../src/client 
/
  +copy file=${external.dir}/jboss-jdbc_ext.jar 
todir=${jboss.dist}/../src/lib /
  +copy file=${external.dir}/jboss-j2ee.jar todir=${jboss.dist}/../src/lib /
 /target
   
 !-- === --
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/client jboss-j2ee.jar

[Scott M Stark]

  User: starksm 
  Date: 01/09/10 09:38:59

  Modified:src/client Tag: Branch_2_4 jboss-j2ee.jar
  Log:
  Synch up the jars from jboss-j2ee
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.4.1   +140 -127  jboss/src/client/Attic/jboss-j2ee.jar
  
Binary file
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/lib jboss-j2ee.jar jboss-jdbc_ext.jar

[Scott M Stark]

  User: starksm 
  Date: 01/09/10 09:38:59

  Modified:src/lib  Tag: Branch_2_4 jboss-j2ee.jar jboss-jdbc_ext.jar
  Log:
  Synch up the jars from jboss-j2ee
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.4.1   +135 -134  jboss/src/lib/Attic/jboss-j2ee.jar
  
Binary file
  
  
  1.2.4.1   +17 -17jboss/src/lib/Attic/jboss-jdbc_ext.jar
  
Binary file
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: newsite/src/docs binary.jsp

[Scott M Stark]

  User: starksm 
  Date: 01/09/10 09:51:53

  Modified:src/docs binary.jsp
  Log:
  Update 2.4.1 info for repackaging
  
  Revision  ChangesPath
  1.4   +6 -9  newsite/src/docs/binary.jsp
  
  Index: binary.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/binary.jsp,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- binary.jsp2001/09/09 17:13:30 1.3
  +++ binary.jsp2001/09/10 16:51:53 1.4
  @@ -39,14 +39,14 @@
 
 tr
   tda class=link 
href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1.zip;JBoss-2.4.1.zip/a/td
  -td align=centerp class=text8378769/td
  -td align=centerp class=textSetempter 9, 2001/td
  +td align=centerp class=text8379911/td
  +td align=centerp class=textSetempter 10, 2001/td
 /tr
   
 tr
   tda class=link 
href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1_Tomcat-3.2.3.zip;JBoss-2.4.1_Tomcat-3.2.3.zip/a/td
  -td align=centerp class=text9016518/td
  -td align=centerp class=textSetempter 9, 2001/td
  +td align=centerp class=text11690110/td
  +td align=centerp class=textSetempter 10, 2001/td
 /tr
   
 tr
  @@ -56,14 +56,11 @@
 /tr
   
   /table
  - pa class=link href=http://www.jboss.org/survey/index.jsp;
  -   the time to fill out the survey,
  - /a
   br
   a class=link href=changelog_2_4_beta.jspChange Log/a for version 2.4.x.
  -
  -p class=headJBoss 2.2.2
   
  + hr
  +p class=headJBoss 2.2.2
   p class=text
   
   table border=0
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Scott M Stark]

 Hi,
 
 I'd like to fix the org.jboss.logging deprecation messages - which
 means replacing the logging with log4j calls...
 
 So - is anyone doing this already?
 
 I plan to look for code that has the correct logging and doing
 like-wise - so any recommendations?
What do you mean by changing code that has the correct logging?

 
 I am assuming that there is no reason for not fully switching over to
 log4j...
 
No reason not to.

 Regards,
 Chris
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Jboss 2.4.1

[Scott M Stark]

I synched up the jboss-j2ee.jar from client and lib with the jboss-j2ee
module
and repackaged the 2.4.1 release bundles.

- Original Message -
From: Vincent Harcq [EMAIL PROTECTED]
To: Dev JBoss [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 1:27 AM
Subject: [JBoss-dev] Jboss 2.4.1


 Hi,
 Under branch 2.4.1.
 jboss-j2ee.jar in src/client and src/lib are not the same, the one in
client
 does not contain EJB 2.0 classes.
 Regards.
 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] Mbean package deployment and undeployment

[David Jencks]

I thought I'd write a note explaining what my recent changes to the mbean
deployment in rh do.

1. Recursive deployment.  The classpath elements in a *service.xml file may
be used to specify dependencies on jar and zip archives, sar archives
(containing a jboss-service.xml file), or *-service.xml files.  Each listed
dependency is loaded before the mbeans in the current *service.xml file are
created and started.  There's a test case for this in jmx.  This
functionality is actually used in the current jboss: jbossmq-service.xml is
in the deploy/lib directory, and is autodeployed after the core
jboss-service.xml.  jbossmq-service.xml depends on jbosscx.sar (due to the
jmsra resource adapter), so jbosscx.sar is recursively deployed.

2. Recursive undeployment based on package dependencies.  If C depends on B
which in turn depends on A, as just noted deploying C will deploy A, then
B, then C.  Recursive undeployment means undeploying A will undeploy B and
C.  Redeploying A will redeploy B and C automatically.

3. Undeploying a package actually works. Mbeans specified in the package
are removed, and the classes from the codebase are removed from the
classloader system (if they are not also deployed by another package not
dependent on the one you are undeploying). There are test for this in jmx.

(As part of the jbosscx reorganization, all jca related classes are in the
jbosscx.sar, which contains the mbean configuration for the
ConnectionManagerFactoryLoaders and the RARDeployer.  The jbossmq
configuration is now in a jbossmq-service.xml file, which depends on the
jbosscx.sar ( and causes it to be recursively deployed).  The configuration
for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is
also autodeployed.)

The classpath element in a *service.xml file works like this:

attribute codebase
  -- if missing, specifies the jboss.system.libraryDirectory set on startup
  -- if . specifies the same directory as the current file is in (not
tested with http)
  -- if a url, specifies the url.

attribute archives is a comma delimited list of jar, zip, sar, and
*service.xml packages the current package depends on.

If the archives attribute is missing and the codebase is a file url, all
jar and zip files in the directory are added.

There can now be multiple classpath elements.

Known problems:
Currently, deploying an already deployed package undeploys and (re) deploys
it.  This can cause churn if you are autodeploying a set of interdependent
packages.  Say C depends on B which depends on A.  If the autodeployed
picks C to deploy first, when it deploys B C will be undeployed and
redeployed, and when it deploys A B and C will be undeployed and
redeployed.  I can think of 2 solutions:

a. deploying an already deployed packaged does nothing.  To refresh,
undeploy and redeploy.  I like this one, but it changes current behavior.

b. The autodeployer keeps track of a autodeployment session and recieves
notifications of deployed packages.  It doesn't try to deploy anything it
received a deploy notification for in the current session.

All comments appreciated.

thanks
david jencks

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Build Problems

[Andreas Schaefer]

Hi Geeks

I run into several problems with the new build system:

jboss-all:

- I can't compile Jetty to get the webserver running

jboss-website:

- Whatever I build the manual is builded but not the website

Any ideas ?

Andy


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] PK Class and Field

[Vincent Harcq]

Hi,
I had some problem recently with a PK Class and how JawsEMD build the list
of pk fields.
I have a PK class APK with a public field code.
I also have a PK class BPK that extends APK and also re-define code (ok
strange but why not)

This line (of JawsEMD)
Field[] pkClassFields = primaryKeyClass.getFields();
return 2 entries.
That causes problems after in finding the entity bean, etc...
I would think it only return one.  Am i wrong here ?
I have a patch for that, but I would like to know if I misunderstood teh
getFields() method.
I am running 1.3.1_01.
Regards.

Vincent.



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Chris Kimpton]

Hi,

--- Scott M Stark [EMAIL PROTECTED] wrote:
 
  
  I plan to look for code that has the correct logging and doing
  like-wise - so any recommendations?
 What do you mean by changing code that has the correct logging?
 

umm, perhaps correct is the wrong phrase.

I mean look for jboss code that is using log4j - I presume some is -
and then use that as a model for making the non-log4j bits use
log4j...

Chris

=
Need somewhere to Live in London - http://freeflats.com

__
Do You Yahoo!?
Get email alerts  NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Scott M Stark]

Ok. Just moving to log4j to avoid deprecation warning is not worth the
effort as we need to define a logging usage pattern and then move to it.
One big issue we have right now is that debug msgs are anything from
verbose one-time initialization mgs to per method traces of activity. The
server.log is inundated with output when any type of client throughput
is seen. For example, running the testsuite produces a 3Mb log file in
9 minutes.

I added a custom TRACE priority to allow finer granularity of debugging
msgs. The notion is that TRACE level msgs are those that are issued as a
result of some request while DEBUG msgs are not. We need to agree on
and formalize our logging convention and then move to it.

- Original Message - 
From: Chris Kimpton [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 11:30 AM
Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?


 Hi,
 
 --- Scott M Stark [EMAIL PROTECTED] wrote:
  
   
   I plan to look for code that has the correct logging and doing
   like-wise - so any recommendations?
  What do you mean by changing code that has the correct logging?
  
 
 umm, perhaps correct is the wrong phrase.
 
 I mean look for jboss code that is using log4j - I presume some is -
 and then use that as a model for making the non-log4j bits use
 log4j...
 
 Chris
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Tomcat Integration into RH

[Andreas Schaefer]

Hi Geeks

Is someone doing the Tomcat integration into RH ??

Andy


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Tomcat Integration into RH

[Scott M Stark]

Eventually.

- Original Message - 
From: Andreas Schaefer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 12:14 PM
Subject: [JBoss-dev] Tomcat Integration into RH


 Hi Geeks
 
 Is someone doing the Tomcat integration into RH ??
 
 Andy
 
 
 ___
 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] Mbean package deployment and undeployment

[Scott M Stark]

For the jbossmq-service.xml example, does reploying jbossmq-service.xml
cause
jboss-service.xml to be undeployed and redeployed?

Likewise, would just undeploying jbossmq-service.xml undeploy
jboss-service.xml?

- Original Message -
From: David Jencks [EMAIL PROTECTED]
To: jboss-dev [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 11:16 AM
Subject: [JBoss-dev] Mbean package deployment and undeployment


 I thought I'd write a note explaining what my recent changes to the mbean
 deployment in rh do.

 1. Recursive deployment.  The classpath elements in a *service.xml file
may
 be used to specify dependencies on jar and zip archives, sar archives
 (containing a jboss-service.xml file), or *-service.xml files.  Each
listed
 dependency is loaded before the mbeans in the current *service.xml file
are
 created and started.  There's a test case for this in jmx.  This
 functionality is actually used in the current jboss: jbossmq-service.xml
is
 in the deploy/lib directory, and is autodeployed after the core
 jboss-service.xml.  jbossmq-service.xml depends on jbosscx.sar (due to the
 jmsra resource adapter), so jbosscx.sar is recursively deployed.

 2. Recursive undeployment based on package dependencies.  If C depends on
B
 which in turn depends on A, as just noted deploying C will deploy A, then
 B, then C.  Recursive undeployment means undeploying A will undeploy B and
 C.  Redeploying A will redeploy B and C automatically.

 3. Undeploying a package actually works. Mbeans specified in the package
 are removed, and the classes from the codebase are removed from the
 classloader system (if they are not also deployed by another package not
 dependent on the one you are undeploying). There are test for this in jmx.

 (As part of the jbosscx reorganization, all jca related classes are in the
 jbosscx.sar, which contains the mbean configuration for the
 ConnectionManagerFactoryLoaders and the RARDeployer.  The jbossmq
 configuration is now in a jbossmq-service.xml file, which depends on the
 jbosscx.sar ( and causes it to be recursively deployed).  The
configuration
 for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which
is
 also autodeployed.)

 The classpath element in a *service.xml file works like this:

 attribute codebase
   -- if missing, specifies the jboss.system.libraryDirectory set on
startup
   -- if . specifies the same directory as the current file is in (not
 tested with http)
   -- if a url, specifies the url.

 attribute archives is a comma delimited list of jar, zip, sar, and
 *service.xml packages the current package depends on.

 If the archives attribute is missing and the codebase is a file url, all
 jar and zip files in the directory are added.

 There can now be multiple classpath elements.

 Known problems:
 Currently, deploying an already deployed package undeploys and (re)
deploys
 it.  This can cause churn if you are autodeploying a set of interdependent
 packages.  Say C depends on B which depends on A.  If the autodeployed
 picks C to deploy first, when it deploys B C will be undeployed and
 redeployed, and when it deploys A B and C will be undeployed and
 redeployed.  I can think of 2 solutions:

 a. deploying an already deployed packaged does nothing.  To refresh,
 undeploy and redeploy.  I like this one, but it changes current behavior.

 b. The autodeployer keeps track of a autodeployment session and recieves
 notifications of deployed packages.  It doesn't try to deploy anything it
 received a deploy notification for in the current session.

 All comments appreciated.

 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] CVS update: newsite/src/docs binary.jsp

[Scott M Stark]

  User: starksm 
  Date: 01/09/10 12:41:57

  Modified:src/docs binary.jsp
  Log:
  Indicate 1.3 is needed for 2.4.x
  
  Revision  ChangesPath
  1.5   +1 -2  newsite/src/docs/binary.jsp
  
  Index: binary.jsp
  ===
  RCS file: /cvsroot/jboss/newsite/src/docs/binary.jsp,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- binary.jsp2001/09/10 16:51:53 1.4
  +++ binary.jsp2001/09/10 19:41:57 1.5
  @@ -15,8 +15,7 @@
p class=headDOWNLOAD THE JBOSS SERVER PRODUCTS TODAY!
   
p class=text
  -  JBoss 2.4.1 is our current bstable/b version. It will run on both
  -  1.2.2 and 1.3 JVMs.
  +  JBoss 2.4.1 is our current bstable/b version. It will run on 1.3+ JVMs.
   
p class=text
 This is our full suite of products and it is likely to be all you will
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[David Jencks]

Hi,
So far I have been unsuccessful in turning on the TRACE priority -- thus
the excessive DEBUG stuff I have been using.  Do you have an example of how
to turn it on?  If I can get it to work I will happily turn most of my
debugs into traces.

Thanks
david jencks

On 2001.09.10 15:12:06 -0400 Scott M Stark wrote:
 Ok. Just moving to log4j to avoid deprecation warning is not worth the
 effort as we need to define a logging usage pattern and then move to it.
 One big issue we have right now is that debug msgs are anything from
 verbose one-time initialization mgs to per method traces of activity. The
 server.log is inundated with output when any type of client throughput
 is seen. For example, running the testsuite produces a 3Mb log file in
 9 minutes.
 
 I added a custom TRACE priority to allow finer granularity of debugging
 msgs. The notion is that TRACE level msgs are those that are issued as a
 result of some request while DEBUG msgs are not. We need to agree on
 and formalize our logging convention and then move to it.
 
 - Original Message - 
 From: Chris Kimpton [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, September 10, 2001 11:30 AM
 Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?
 
 
  Hi,
  
  --- Scott M Stark [EMAIL PROTECTED] wrote:
   

I plan to look for code that has the correct logging and doing
like-wise - so any recommendations?
   What do you mean by changing code that has the correct logging?
   
  
  umm, perhaps correct is the wrong phrase.
  
  I mean look for jboss code that is using log4j - I presume some is -
  and then use that as a model for making the non-log4j bits use
  log4j...
  
  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: [JBoss-dev] Mbean package deployment and undeployment

[David Jencks]

On 2001.09.10 15:39:58 -0400 Scott M Stark wrote:
 For the jbossmq-service.xml example, does reploying jbossmq-service.xml
 cause
 jboss-service.xml to be undeployed and redeployed?

No, jboss-service.xml is not listed as a dependency of jbossmq-service.xml.
 
 Likewise, would just undeploying jbossmq-service.xml undeploy
 jboss-service.xml?

In the current situation, as just noted, no.  Hmmm. If it was listed, I
think it would undeploy, which seems like a bad idea.  

What would be the desirable behavior in these scenarios?

1. B and C both depend on A. B and C are explicitly deployed, causing A to
be recursively deployed.  B is undeployed.  What happens?
- A remains deployed, since C is still depending on it. (good, I think)
- A is undeployed, causing C to be undeployed. (bad, I think)

assuming A remains deployed, then undeploy C
- A is now undeployed, since nothing depends on it and it was not
explicitly deployed. (good, I think)
- A remains deployed. (bad, I think)

2. B depends on A. A and B are explicitly deployed. B is undeployed. No
other packages depend on A.
- A remaings deployed, since it was explicitly deployed (good, I think)
- A is undeployed since nothing depends on it.(bad, I think)


any opinions or other scenarios?

david jencks


 
 - Original Message -
 From: David Jencks [EMAIL PROTECTED]
 To: jboss-dev [EMAIL PROTECTED]
 Sent: Monday, September 10, 2001 11:16 AM
 Subject: [JBoss-dev] Mbean package deployment and undeployment
 
 
  I thought I'd write a note explaining what my recent changes to the
 mbean
  deployment in rh do.
 
  1. Recursive deployment.  The classpath elements in a *service.xml file
 may
  be used to specify dependencies on jar and zip archives, sar archives
  (containing a jboss-service.xml file), or *-service.xml files.  Each
 listed
  dependency is loaded before the mbeans in the current *service.xml file
 are
  created and started.  There's a test case for this in jmx.  This
  functionality is actually used in the current jboss:
 jbossmq-service.xml
 is
  in the deploy/lib directory, and is autodeployed after the core
  jboss-service.xml.  jbossmq-service.xml depends on jbosscx.sar (due to
 the
  jmsra resource adapter), so jbosscx.sar is recursively deployed.
 
  2. Recursive undeployment based on package dependencies.  If C depends
 on
 B
  which in turn depends on A, as just noted deploying C will deploy A,
 then
  B, then C.  Recursive undeployment means undeploying A will undeploy B
 and
  C.  Redeploying A will redeploy B and C automatically.
 
  3. Undeploying a package actually works. Mbeans specified in the
 package
  are removed, and the classes from the codebase are removed from the
  classloader system (if they are not also deployed by another package
 not
  dependent on the one you are undeploying). There are test for this in
 jmx.
 
  (As part of the jbosscx reorganization, all jca related classes are in
 the
  jbosscx.sar, which contains the mbean configuration for the
  ConnectionManagerFactoryLoaders and the RARDeployer.  The jbossmq
  configuration is now in a jbossmq-service.xml file, which depends on
 the
  jbosscx.sar ( and causes it to be recursively deployed).  The
 configuration
  for the Hypersonic-based DefaultDS is in hsql-default-service.xml,
 which
 is
  also autodeployed.)
 
  The classpath element in a *service.xml file works like this:
 
  attribute codebase
-- if missing, specifies the jboss.system.libraryDirectory set on
 startup
-- if . specifies the same directory as the current file is in (not
  tested with http)
-- if a url, specifies the url.
 
  attribute archives is a comma delimited list of jar, zip, sar, and
  *service.xml packages the current package depends on.
 
  If the archives attribute is missing and the codebase is a file url,
 all
  jar and zip files in the directory are added.
 
  There can now be multiple classpath elements.
 
  Known problems:
  Currently, deploying an already deployed package undeploys and (re)
 deploys
  it.  This can cause churn if you are autodeploying a set of
 interdependent
  packages.  Say C depends on B which depends on A.  If the autodeployed
  picks C to deploy first, when it deploys B C will be undeployed and
  redeployed, and when it deploys A B and C will be undeployed and
  redeployed.  I can think of 2 solutions:
 
  a. deploying an already deployed packaged does nothing.  To refresh,
  undeploy and redeploy.  I like this one, but it changes current
 behavior.
 
  b. The autodeployer keeps track of a autodeployment session and
 recieves
  notifications of deployed packages.  It doesn't try to deploy anything
 it
  received a deploy notification for in the current session.
 
  All comments appreciated.
 
  thanks
  david jencks
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 
 
 
 ___
 

Re: [JBoss-dev] Mbean package deployment and undeployment

[Hiram Chirino]

From: David Jencks [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: jboss-dev [EMAIL PROTECTED]
Subject: [JBoss-dev] Mbean package deployment and undeployment
Date: Mon, 10 Sep 2001 14:16:17 -0400


(As part of the jbosscx reorganization, all jca related classes are in the
jbosscx.sar, which contains the mbean configuration for the
ConnectionManagerFactoryLoaders and the RARDeployer.  The jbossmq
configuration is now in a jbossmq-service.xml file, which depends on the
jbosscx.sar ( and causes it to be recursively deployed).  The configuration
for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is
also autodeployed.)


JBossMQ does not depend on jbosscx.sar...  The MDB and JMS RA stuff is what 
depends on jbosscx.sar.  the jbossmq-service.xml file needs to get split 
into two files to show this.

Regards,
Hiram


_
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] log4j switchover - anyone working on this?

[Scott M Stark]

Yes, there is an example in the default log4j.properties file that is
commented
out. Simply uncomment the last line as follows:

# An example of enabling the custom TRACE level priority that is used
# by the JBoss internals to diagnose low level details. This example
# turns on TRACE level msgs for the org.jboss.ejb.plugins package and its
# subpackages. This will produce A LOT of logging output.
log4j.category.org.jboss.ejb.plugins=TRACE#org.jboss.logging.log4j.TracePrio
rity

If you now invoke an ejb method you will see a large number of messages
detailing
the activity of the Entity instance locking for example(provided that was
not dropped
in the RH changes).

Before rushing off to switch to using this custom priority however, I would
like
to have an agreement that is the best way to do this.

- Original Message -
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 12:54 PM
Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?


 Hi,
 So far I have been unsuccessful in turning on the TRACE priority -- thus
 the excessive DEBUG stuff I have been using.  Do you have an example of
how
 to turn it on?  If I can get it to work I will happily turn most of my
 debugs into traces.

 Thanks
 david jencks

 On 2001.09.10 15:12:06 -0400 Scott M Stark wrote:
  Ok. Just moving to log4j to avoid deprecation warning is not worth the
  effort as we need to define a logging usage pattern and then move to it.
  One big issue we have right now is that debug msgs are anything from
  verbose one-time initialization mgs to per method traces of activity.
The
  server.log is inundated with output when any type of client throughput
  is seen. For example, running the testsuite produces a 3Mb log file in
  9 minutes.
 
  I added a custom TRACE priority to allow finer granularity of debugging
  msgs. The notion is that TRACE level msgs are those that are issued as a
  result of some request while DEBUG msgs are not. We need to agree on
  and formalize our logging convention and then move to it.
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Mbean package deployment and undeployment

[Scott M Stark]

 On 2001.09.10 15:39:58 -0400 Scott M Stark wrote:
  For the jbossmq-service.xml example, does reploying jbossmq-service.xml
  cause
  jboss-service.xml to be undeployed and redeployed?

 No, jboss-service.xml is not listed as a dependency of
jbossmq-service.xml.
But JBossMQ requires that a JNDI naming service be present, so how is that
dependency specified? Also in the future I want to make better use of the
JBossSX framework for authentication and authorization in other JBoss
services
to avoid the passwords spread all over the place configuration issue we
now
have so this is another future core service dependency.

 
  Likewise, would just undeploying jbossmq-service.xml undeploy
  jboss-service.xml?

 In the current situation, as just noted, no.  Hmmm. If it was listed, I
 think it would undeploy, which seems like a bad idea.

 What would be the desirable behavior in these scenarios?

 1. B and C both depend on A. B and C are explicitly deployed, causing A to
 be recursively deployed.  B is undeployed.  What happens?
 - A remains deployed, since C is still depending on it. (good, I think)
 - A is undeployed, causing C to be undeployed. (bad, I think)

A should remain deployed.

 assuming A remains deployed, then undeploy C
 - A is now undeployed, since nothing depends on it and it was not
 explicitly deployed. (good, I think)
 - A remains deployed. (bad, I think)

Things are not this black and white. Just because I don't have any services
deployed that depend on A does not mean that it should be undeployed. The
naming service is a perfect example. Just because I don't have any services
deployed that depend on the naming service does not mean that I don't have
external clients using the naming service.


 2. B depends on A. A and B are explicitly deployed. B is undeployed. No
 other packages depend on A.
 - A remaings deployed, since it was explicitly deployed (good, I think)
 - A is undeployed since nothing depends on it.(bad, I think)

A remains deployed, since it was explicitly deployed. This is the naming
service
example as it will be explictly deployed and many other services will depend
on it.



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Renaming tests?

[David Jencks]

I'd like to do something about the test suite so we have separate unit
(fast) and stress (slow) test suites and so the test script doesn't try to
execute non test classes as tests.

How about this naming convention:

*UnitTest.java indicates a class containing only quick, unit tests.

*StressTest.java indicates a class containing (only) lengthy iterative
tests.

Anything else with Test in its name is not considered to be a test and is
not executed.

For a first iteration I will rename all test classes so that a class with
any lengthy tests is a *StressTest.  Later we can split them into two
classes, unit and stress (assuming there are any with unit and stress tests
in the same class).

Any problems with this?

thanks
david jencks

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Mbean package deployment and undeployment

[David Jencks]

Thanks, Hiram


Are the attached files what you mean? (I haven't tested to make sure they
work).

Is some part of the jbossmq-service.jar required for jbossmq to work,
whereas the rest is an example of how to set up usage of it?  If so, can we
package the required part into a jboss-service.xml in a sar?  If you let me
know which parts are required/optional I will try out the packaging.

Thanks
david jencks


On 2001.09.10 16:18:57 -0400 Hiram Chirino wrote:
 From: David Jencks [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: jboss-dev [EMAIL PROTECTED]
 Subject: [JBoss-dev] Mbean package deployment and undeployment
 Date: Mon, 10 Sep 2001 14:16:17 -0400
 
 
 (As part of the jbosscx reorganization, all jca related classes are in
 the
 jbosscx.sar, which contains the mbean configuration for the
 ConnectionManagerFactoryLoaders and the RARDeployer.  The jbossmq
 configuration is now in a jbossmq-service.xml file, which depends on the
 jbosscx.sar ( and causes it to be recursively deployed).  The
 configuration
 for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which
 is
 also autodeployed.)
 
 
 JBossMQ does not depend on jbosscx.sar...  The MDB and JMS RA stuff is
 what 
 depends on jbosscx.sar.  the jbossmq-service.xml file needs to get split 
 into two files to show this.
 
 Regards,
 Hiram
 
 
 _
 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
 
 


?xml version=1.0 encoding=UTF-8?


!-- = --
!--   --
!--  JBoss Server Configuration   --
!--   --
!-- = --

!-- $Id: jbossmq-service.xml,v 1.2 2001/09/09 05:40:47 d_jencks Exp $ --

!-- 
   |  This is where you can add and configure your MBeans.
   |
   |  *ATTENTION*
   |
   |  The order of the listing here is the same order as
   |  the MBeans are loaded. Therefore if a MBean depends on another
   |  MBean to be loaded and started it has to be listed after all
   |  the MBeans it depends on.
  --


server



  classpath archives=
jbossmq.jar/

  !--  --
  !-- JBossMQ  --
  !--  --

  mbean code=org.jboss.mq.server.JBossMQService
	 name=JBossMQ:service=Server/

  !-- 
 | The StateManager is used to keep JMS perisitent state data.
 | For example: what durable subscriptions are active. 
   --
  mbean code=org.jboss.mq.server.StateManager 
	 name=JBossMQ:service=StateManager
attribute name=StateFileconf/default/jbossmq-state.xml/attribute
  /mbean

  !-- The PersistenceManager is used to store messages to disk. --
  mbean code=org.jboss.mq.pm.file.PersistenceManager
	 name=JBossMQ:service=PersistenceManager
attribute name=DataDirectorydb/jbossmq//attribute
  /mbean

  !-- 
 | InvocationLayers are the different transport methods that can 
 | be used to access the server.
   --
  mbean code=org.jboss.mq.il.jvm.JVMServerILService
	 name=JBossMQ:service=InvocationLayer,type=JVM
attribute name=ConnectionFactoryJNDIRefjava:/ConnectionFactory/attribute
attribute name=XAConnectionFactoryJNDIRefjava:/XAConnectionFactory/attribute
  /mbean

  mbean code=org.jboss.mq.il.rmi.RMIServerILService
	 name=JBossMQ:service=InvocationLayer,type=RMI 
attribute name=ConnectionFactoryJNDIRefRMIConnectionFactory/attribute
attribute name=XAConnectionFactoryJNDIRefRMIXAConnectionFactory/attribute
  /mbean

  mbean code=org.jboss.mq.il.oil.OILServerILService
	 name=JBossMQ:service=InvocationLayer,type=OIL
attribute name=ConnectionFactoryJNDIRefConnectionFactory/attribute
attribute name=XAConnectionFactoryJNDIRefXAConnectionFactory/attribute
  /mbean

  mbean code=org.jboss.mq.il.uil.UILServerILService
	 name=JBossMQ:service=InvocationLayer,type=UIL
attribute name=ConnectionFactoryJNDIRefUILConnectionFactory/attribute
attribute name=XAConnectionFactoryJNDIRefUILXAConnectionFactory/attribute
  /mbean

  !-- 
 | The following three line create 3 topics named: 
 |
 |   testTopic, example, bob
   --
  mbean code=org.jboss.mq.server.TopicManager
	 name=JBossMQ:service=Topic,name=testTopic/
  mbean code=org.jboss.mq.server.TopicManager
	 name=JBossMQ:service=Topic,name=example/
  mbean code=org.jboss.mq.server.TopicManager 
	 name=JBossMQ:service=Topic,name=bob/

  !-- 
 | The following 9 line create 9 topics named: 
 |
 |   

Re: [JBoss-dev] Renaming tests?

[Scott M Stark]

The last suggested naming convention was *TestCase.java so:

*TestCase.java indicates a class containing only quick, unit tests.

*StressTestCase.java indicates a class containing (only) lengthy iterative
tests.

- Original Message -
From: David Jencks [EMAIL PROTECTED]
To: jboss-dev [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 1:43 PM
Subject: [JBoss-dev] Renaming tests?


 I'd like to do something about the test suite so we have separate unit
 (fast) and stress (slow) test suites and so the test script doesn't try to
 execute non test classes as tests.

 How about this naming convention:

 *UnitTest.java indicates a class containing only quick, unit tests.

 *StressTest.java indicates a class containing (only) lengthy iterative
 tests.

 Anything else with Test in its name is not considered to be a test and is
 not executed.

 For a first iteration I will rename all test classes so that a class with
 any lengthy tests is a *StressTest.  Later we can split them into two
 classes, unit and stress (assuming there are any with unit and stress
tests
 in the same class).

 Any problems with this?

 thanks
 david jencks




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Mbean package deployment and undeployment

[David Maplesden]

Time for my two cents...

I have just finished incorporating my scheme (the use of the depends
elements) with David J's and it seems to work for the simple examples I have
tested it on.  I am a bit unsure whether or not to commit the changes (after
more testing) though because the two schemes don't mesh particularly well in
the source.  Some odd behaviour would be possible if deployments attempt to
use both mechanisms at the same time.

In my opinion some of the problems or discussion points that are coming up
in this thread are because the recursive deployment model is not always
suitable, when all you want to do is specify a simple dependency.  The
naming service (JNDI) is a classic example, where many of the other services
need this service to be started before they will successfully start but it
is easy to deploy on its own.

The recursive deployment mechanism I feel is excellent for deploying and
undeploying applications that are spread across multiple sar's and comprise
multiple mbean services.  I don't think it is so effective at specifying
simple dependencies between services, especially the core ones that exist
during the startup process.

David

 -Original Message-
 From: Scott M Stark [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, September 11, 2001 8:42 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
 
 
 
  On 2001.09.10 15:39:58 -0400 Scott M Stark wrote:
   For the jbossmq-service.xml example, does reploying 
 jbossmq-service.xml
   cause
   jboss-service.xml to be undeployed and redeployed?
 
  No, jboss-service.xml is not listed as a dependency of
 jbossmq-service.xml.
 But JBossMQ requires that a JNDI naming service be present, 
 so how is that
 dependency specified? Also in the future I want to make 
 better use of the
 JBossSX framework for authentication and authorization in other JBoss
 services
 to avoid the passwords spread all over the place 
 configuration issue we
 now
 have so this is another future core service dependency.
 
  
   Likewise, would just undeploying jbossmq-service.xml undeploy
   jboss-service.xml?
 
  In the current situation, as just noted, no.  Hmmm. If it 
 was listed, I
  think it would undeploy, which seems like a bad idea.
 
  What would be the desirable behavior in these scenarios?
 
  1. B and C both depend on A. B and C are explicitly 
 deployed, causing A to
  be recursively deployed.  B is undeployed.  What happens?
  - A remains deployed, since C is still depending on it. 
 (good, I think)
  - A is undeployed, causing C to be undeployed. (bad, I think)
 
 A should remain deployed.
 
  assuming A remains deployed, then undeploy C
  - A is now undeployed, since nothing depends on it and it was not
  explicitly deployed. (good, I think)
  - A remains deployed. (bad, I think)
 
 Things are not this black and white. Just because I don't 
 have any services
 deployed that depend on A does not mean that it should be 
 undeployed. The
 naming service is a perfect example. Just because I don't 
 have any services
 deployed that depend on the naming service does not mean that 
 I don't have
 external clients using the naming service.
 
 
  2. B depends on A. A and B are explicitly deployed. B is 
 undeployed. No
  other packages depend on A.
  - A remaings deployed, since it was explicitly deployed 
 (good, I think)
  - A is undeployed since nothing depends on it.(bad, I think)
 
 A remains deployed, since it was explicitly deployed. This is 
 the naming
 service
 example as it will be explictly deployed and many other 
 services will depend
 on it.
 
 
 
 ___
 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 2.4.1

[Julian Gosnell]

Scott,

Do you mean that you have edited the 2.4.1 release on SourceForge ?

If so, I need to trash the 2.4.1/Jetty release I am doing and start aain
on the new release.


Thanks,


Jules


Scott M Stark wrote:

 I synched up the jboss-j2ee.jar from client and lib with the jboss-j2ee
 module
 and repackaged the 2.4.1 release bundles.

 - Original Message -
 From: Vincent Harcq [EMAIL PROTECTED]
 To: Dev JBoss [EMAIL PROTECTED]
 Sent: Monday, September 10, 2001 1:27 AM
 Subject: [JBoss-dev] Jboss 2.4.1

  Hi,
  Under branch 2.4.1.
  jboss-j2ee.jar in src/client and src/lib are not the same, the one in
 client
  does not contain EJB 2.0 classes.
  Regards.
  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


_
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] Mbean package deployment and undeployment

[Hiram Chirino]

Yes..  almost perfect.  Just move the
- !--  The JMS provider loader
  --
- mbean code=org.jboss.jms.jndi.JMSProviderLoader 
name=:service=JMSProviderLoader,name=JBossMQProvider
  attribute name=ProviderNameDefaultJMSProvider/attribute
  attribute 
name=ProviderAdapterClassorg.jboss.jms.jndi.JBossMQProvider/attribute
  attribute name=QueueFactoryRefjava:/XAConnectionFactory/attribute
  attribute name=TopicFactoryRefjava:/XAConnectionFactory/attribute
  /mbean

section into the ra xml file.

Regards,
Hiram

From: David Jencks [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
Date: Mon, 10 Sep 2001 16:55:02 -0400

Thanks, Hiram


Are the attached files what you mean? (I haven't tested to make sure they
work).

Is some part of the jbossmq-service.jar required for jbossmq to work,
whereas the rest is an example of how to set up usage of it?  If so, can we
package the required part into a jboss-service.xml in a sar?  If you let me
know which parts are required/optional I will try out the packaging.

Thanks
david jencks


On 2001.09.10 16:18:57 -0400 Hiram Chirino wrote:
  From: David Jencks [EMAIL PROTECTED]
  Reply-To: [EMAIL PROTECTED]
  To: jboss-dev [EMAIL PROTECTED]
  Subject: [JBoss-dev] Mbean package deployment and undeployment
  Date: Mon, 10 Sep 2001 14:16:17 -0400
  
  
  (As part of the jbosscx reorganization, all jca related classes are in
  the
  jbosscx.sar, which contains the mbean configuration for the
  ConnectionManagerFactoryLoaders and the RARDeployer.  The jbossmq
  configuration is now in a jbossmq-service.xml file, which depends on 
the
  jbosscx.sar ( and causes it to be recursively deployed).  The
  configuration
  for the Hypersonic-based DefaultDS is in hsql-default-service.xml, 
which
  is
  also autodeployed.)
  
 
  JBossMQ does not depend on jbosscx.sar...  The MDB and JMS RA stuff is
  what
  depends on jbosscx.sar.  the jbossmq-service.xml file needs to get split
  into two files to show this.
 
  Regards,
  Hiram
 
 
  _
  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
 
 
 jbossmq-service.xml 
 jbossmq-ra-service.xml 


_
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] Mbean package deployment and undeployment

[David Maplesden]

Whatever happened to Simple is the word...   ;-)

David


 -Original Message-
 From: David Jencks [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, September 11, 2001 9:24 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
 
 
 Ok, my thinking is coming into focus. Here's what I'd like to 
 implement:
 
 We distinguish between explicitly and implicitly (ie due to recursive
 deployment) deployed packages.
 
 deploying a package will recursively (implicitly) deploy all 
 packages it
 depends on (as determined by looking at the classpath 
 elements) that aren't
 already deployed. (this happens now)
 
 undeploying a package will undeploy (suspend) all packages 
 that depend on
 it (works now) and will undeploy all implicitly deployed packages it
 depends on that aren't used by other deployed packages.  Undeploying a
 package A will never undeploy a package B it depends on if B has been
 explicitly deployed.
 
 undeploying and redeploying a package will undeploy and redeploy all
 packages that depend on it. (works now)
 
 If B depends on A, both are deployed, then A is undeployed 
 (undeploying and
 suspending B), trying to undeploy B will remove the 
 suspension dependency,
 so that when A is redeployed, B will not be redeployed. 
 
 To redeploy a package, you must explicitly undeploy it and 
 redeploy it. 
 This changes current behavior where updating a package redeploys it.
 
 
 Any more rules I need?
 
 
 Thanks
 david jencks
 
 On 2001.09.10 16:41:54 -0400 Scott M Stark wrote:
  
   On 2001.09.10 15:39:58 -0400 Scott M Stark wrote:
For the jbossmq-service.xml example, does reploying
  jbossmq-service.xml
cause
jboss-service.xml to be undeployed and redeployed?
  
   No, jboss-service.xml is not listed as a dependency of
  jbossmq-service.xml.
  But JBossMQ requires that a JNDI naming service be present, 
 so how is
  that
  dependency specified? 
 right now, not at all: this is a problem.
 
 Also in the future I want to make better use of the
  JBossSX framework for authentication and authorization in 
 other JBoss
  services
  to avoid the passwords spread all over the place 
 configuration issue we
  now
  have so this is another future core service dependency.
  
   
Likewise, would just undeploying jbossmq-service.xml undeploy
jboss-service.xml?
  
   In the current situation, as just noted, no.  Hmmm. If it 
 was listed, I
   think it would undeploy, which seems like a bad idea.
  
   What would be the desirable behavior in these scenarios?
  
   1. B and C both depend on A. B and C are explicitly 
 deployed, causing A
  to
   be recursively deployed.  B is undeployed.  What happens?
   - A remains deployed, since C is still depending on it. 
 (good, I think)
   - A is undeployed, causing C to be undeployed. (bad, I think)
  
  A should remain deployed.
  
   assuming A remains deployed, then undeploy C
   - A is now undeployed, since nothing depends on it and it was not
   explicitly deployed. (good, I think)
   - A remains deployed. (bad, I think)
  
  Things are not this black and white. Just because I don't have any
  services
  deployed that depend on A does not mean that it should be 
 undeployed. The
  naming service is a perfect example. Just because I don't have any
  services
  deployed that depend on the naming service does not mean 
 that I don't
  have
  external clients using the naming service.
  
  
   2. B depends on A. A and B are explicitly deployed. B is 
 undeployed. No
   other packages depend on A.
   - A remaings deployed, since it was explicitly deployed 
 (good, I think)
   - A is undeployed since nothing depends on it.(bad, I think)
  
  A remains deployed, since it was explicitly deployed. This 
 is the naming
  service
  example as it will be explictly deployed and many other 
 services will
  depend
  on it.
  
  
  
  ___
  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] Renaming tests?

[Jason Dillon]

This sounds good.

--jason


On Mon, 10 Sep 2001, Scott M Stark wrote:

 The last suggested naming convention was *TestCase.java so:

 *TestCase.java indicates a class containing only quick, unit tests.

 *StressTestCase.java indicates a class containing (only) lengthy iterative
 tests.

 - Original Message -
 From: David Jencks [EMAIL PROTECTED]
 To: jboss-dev [EMAIL PROTECTED]
 Sent: Monday, September 10, 2001 1:43 PM
 Subject: [JBoss-dev] Renaming tests?


  I'd like to do something about the test suite so we have separate unit
  (fast) and stress (slow) test suites and so the test script doesn't try to
  execute non test classes as tests.
 
  How about this naming convention:
 
  *UnitTest.java indicates a class containing only quick, unit tests.
 
  *StressTest.java indicates a class containing (only) lengthy iterative
  tests.
 
  Anything else with Test in its name is not considered to be a test and is
  not executed.
 
  For a first iteration I will rename all test classes so that a class with
  any lengthy tests is a *StressTest.  Later we can split them into two
  classes, unit and stress (assuming there are any with unit and stress
 tests
  in the same class).
 
  Any problems with this?
 
  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

Re: [JBoss-dev] Mbean package deployment and undeployment

[David Jencks]

Well,
after struggling to get a working jboss startup using only the recursive
dependencies, I am inclined to agree with you that relying solely on them
is not necessarily appropriate.  I don't know a good final answer:

--recursive deployment is nice because it lets you aggregate chunks of
deployment at many levels, and only explicitly deploy the top level.

--mbean dependencies are nice because often you don't care where the code
/configuration for the service is, you just need to make sure it's there.

I'd say, if your stuff doesn't break the current startup, or you have a
modified startup that works, and you have (or plan to have) at least some
minimal tests, commit it.  I'd like to see it and make the
explicit/implicit deployment/undeployment on top of it.  We can work out
the best balance between the actual use of the two schemes by experiment
and discussion.

Thanks
Cant wait!
david jencks

On 2001.09.10 16:47:32 -0400 David Maplesden wrote:
 Time for my two cents...
 
 I have just finished incorporating my scheme (the use of the depends
 elements) with David J's and it seems to work for the simple examples I
 have
 tested it on.  I am a bit unsure whether or not to commit the changes
 (after
 more testing) though because the two schemes don't mesh particularly well
 in
 the source.  Some odd behaviour would be possible if deployments attempt
 to
 use both mechanisms at the same time.
 
 In my opinion some of the problems or discussion points that are coming
 up
 in this thread are because the recursive deployment model is not always
 suitable, when all you want to do is specify a simple dependency.  The
 naming service (JNDI) is a classic example, where many of the other
 services
 need this service to be started before they will successfully start but
 it
 is easy to deploy on its own.
 
 The recursive deployment mechanism I feel is excellent for deploying and
 undeploying applications that are spread across multiple sar's and
 comprise
 multiple mbean services.  I don't think it is so effective at specifying
 simple dependencies between services, especially the core ones that exist
 during the startup process.
 
 David
 
  -Original Message-
  From: Scott M Stark [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, September 11, 2001 8:42 AM
  To: [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
  
  
  
   On 2001.09.10 15:39:58 -0400 Scott M Stark wrote:
For the jbossmq-service.xml example, does reploying 
  jbossmq-service.xml
cause
jboss-service.xml to be undeployed and redeployed?
  
   No, jboss-service.xml is not listed as a dependency of
  jbossmq-service.xml.
  But JBossMQ requires that a JNDI naming service be present, 
  so how is that
  dependency specified? Also in the future I want to make 
  better use of the
  JBossSX framework for authentication and authorization in other JBoss
  services
  to avoid the passwords spread all over the place 
  configuration issue we
  now
  have so this is another future core service dependency.
  
   
Likewise, would just undeploying jbossmq-service.xml undeploy
jboss-service.xml?
  
   In the current situation, as just noted, no.  Hmmm. If it 
  was listed, I
   think it would undeploy, which seems like a bad idea.
  
   What would be the desirable behavior in these scenarios?
  
   1. B and C both depend on A. B and C are explicitly 
  deployed, causing A to
   be recursively deployed.  B is undeployed.  What happens?
   - A remains deployed, since C is still depending on it. 
  (good, I think)
   - A is undeployed, causing C to be undeployed. (bad, I think)
  
  A should remain deployed.
  
   assuming A remains deployed, then undeploy C
   - A is now undeployed, since nothing depends on it and it was not
   explicitly deployed. (good, I think)
   - A remains deployed. (bad, I think)
  
  Things are not this black and white. Just because I don't 
  have any services
  deployed that depend on A does not mean that it should be 
  undeployed. The
  naming service is a perfect example. Just because I don't 
  have any services
  deployed that depend on the naming service does not mean that 
  I don't have
  external clients using the naming service.
  
  
   2. B depends on A. A and B are explicitly deployed. B is 
  undeployed. No
   other packages depend on A.
   - A remaings deployed, since it was explicitly deployed 
  (good, I think)
   - A is undeployed since nothing depends on it.(bad, I think)
  
  A remains deployed, since it was explicitly deployed. This is 
  the naming
  service
  example as it will be explictly deployed and many other 
  services will depend
  on it.
  
  
  
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Jason Dillon]

Are we still planning on dropping the older Log  Logger stuff in favor of
Log4j?  If so, lets replace Logger with a new class that extends from
Category, and provides Logger create() methods to access an instance.  It
would have the trace() and isTraceEnabled().

Trace seems to be best suited for detailed debug messages, which are only
enabled for tracking down server internals.  In most cases I would like to
run JBoss with debug enabled, but I don't want to get flooded with tons of
messages.

IMHO, debug messages should provide adequte brief information, which could
be used to track down a problem, and trace is used to provide as much
information as possible.

--jason


On Mon, 10 Sep 2001, Scott M Stark wrote:

 Yes, there is an example in the default log4j.properties file that is
 commented
 out. Simply uncomment the last line as follows:

 # An example of enabling the custom TRACE level priority that is used
 # by the JBoss internals to diagnose low level details. This example
 # turns on TRACE level msgs for the org.jboss.ejb.plugins package and its
 # subpackages. This will produce A LOT of logging output.
 log4j.category.org.jboss.ejb.plugins=TRACE#org.jboss.logging.log4j.TracePrio
 rity

 If you now invoke an ejb method you will see a large number of messages
 detailing
 the activity of the Entity instance locking for example(provided that was
 not dropped
 in the RH changes).

 Before rushing off to switch to using this custom priority however, I would
 like
 to have an agreement that is the best way to do this.

 - Original Message -
 From: David Jencks [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, September 10, 2001 12:54 PM
 Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?


  Hi,
  So far I have been unsuccessful in turning on the TRACE priority -- thus
  the excessive DEBUG stuff I have been using.  Do you have an example of
 how
  to turn it on?  If I can get it to work I will happily turn most of my
  debugs into traces.
 
  Thanks
  david jencks
 
  On 2001.09.10 15:12:06 -0400 Scott M Stark wrote:
   Ok. Just moving to log4j to avoid deprecation warning is not worth the
   effort as we need to define a logging usage pattern and then move to it.
   One big issue we have right now is that debug msgs are anything from
   verbose one-time initialization mgs to per method traces of activity.
 The
   server.log is inundated with output when any type of client throughput
   is seen. For example, running the testsuite produces a 3Mb log file in
   9 minutes.
  
   I added a custom TRACE priority to allow finer granularity of debugging
   msgs. The notion is that TRACE level msgs are those that are issued as a
   result of some request while DEBUG msgs are not. We need to agree on
   and formalize our logging convention and then move to it.
  



 ___
 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] Build Problems

[Jason Dillon]

 jboss-all:

 - I can't compile Jetty to get the webserver running

I am not sure this really works yet.  I had to use the 2.4.x/Jetty package
to test the website deployment.

 jboss-website:

 - Whatever I build the manual is builded but not the website

Could you explain this in more detail; I don't understand the problem your
are having.

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Mbean package deployment and undeployment

[David Maplesden]

OK, thats good, I wanted your nod before committing, which I will do some
time today.

My stuff doesn't break the current startup and I have made a few changes to
the startup configuration so that it all works nicely.  However I will need
you to look over the changes and check I haven't stuffed up any of your nice
recursive deploy/undeployment things.

 -Original Message-
 From: David Jencks [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, September 11, 2001 9:35 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
 
 
 Well,
 after struggling to get a working jboss startup using only 
 the recursive
 dependencies, I am inclined to agree with you that relying 
 solely on them
 is not necessarily appropriate.  I don't know a good final answer:
 
 --recursive deployment is nice because it lets you aggregate chunks of
 deployment at many levels, and only explicitly deploy the top level.
 
 --mbean dependencies are nice because often you don't care 
 where the code
 /configuration for the service is, you just need to make sure 
 it's there.
 
 I'd say, if your stuff doesn't break the current startup, or 
 you have a
 modified startup that works, and you have (or plan to have) 
 at least some
 minimal tests, commit it.  I'd like to see it and make the
 explicit/implicit deployment/undeployment on top of it.  We 
 can work out
 the best balance between the actual use of the two schemes by 
 experiment
 and discussion.
 
 Thanks
 Cant wait!
 david jencks
 
 On 2001.09.10 16:47:32 -0400 David Maplesden wrote:
  Time for my two cents...
  
  I have just finished incorporating my scheme (the use of the depends
  elements) with David J's and it seems to work for the 
 simple examples I
  have
  tested it on.  I am a bit unsure whether or not to commit 
 the changes
  (after
  more testing) though because the two schemes don't mesh 
 particularly well
  in
  the source.  Some odd behaviour would be possible if 
 deployments attempt
  to
  use both mechanisms at the same time.
  
  In my opinion some of the problems or discussion points 
 that are coming
  up
  in this thread are because the recursive deployment model 
 is not always
  suitable, when all you want to do is specify a simple 
 dependency.  The
  naming service (JNDI) is a classic example, where many of the other
  services
  need this service to be started before they will 
 successfully start but
  it
  is easy to deploy on its own.
  
  The recursive deployment mechanism I feel is excellent for 
 deploying and
  undeploying applications that are spread across multiple sar's and
  comprise
  multiple mbean services.  I don't think it is so effective 
 at specifying
  simple dependencies between services, especially the core 
 ones that exist
  during the startup process.
  
  David
  
   -Original Message-
   From: Scott M Stark [mailto:[EMAIL PROTECTED]]
   Sent: Tuesday, September 11, 2001 8:42 AM
   To: [EMAIL PROTECTED]
   Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
   
   
   
On 2001.09.10 15:39:58 -0400 Scott M Stark wrote:
 For the jbossmq-service.xml example, does reploying 
   jbossmq-service.xml
 cause
 jboss-service.xml to be undeployed and redeployed?
   
No, jboss-service.xml is not listed as a dependency of
   jbossmq-service.xml.
   But JBossMQ requires that a JNDI naming service be present, 
   so how is that
   dependency specified? Also in the future I want to make 
   better use of the
   JBossSX framework for authentication and authorization in 
 other JBoss
   services
   to avoid the passwords spread all over the place 
   configuration issue we
   now
   have so this is another future core service dependency.
   

 Likewise, would just undeploying jbossmq-service.xml undeploy
 jboss-service.xml?
   
In the current situation, as just noted, no.  Hmmm. If it 
   was listed, I
think it would undeploy, which seems like a bad idea.
   
What would be the desirable behavior in these scenarios?
   
1. B and C both depend on A. B and C are explicitly 
   deployed, causing A to
be recursively deployed.  B is undeployed.  What happens?
- A remains deployed, since C is still depending on it. 
   (good, I think)
- A is undeployed, causing C to be undeployed. (bad, I think)
   
   A should remain deployed.
   
assuming A remains deployed, then undeploy C
- A is now undeployed, since nothing depends on it and 
 it was not
explicitly deployed. (good, I think)
- A remains deployed. (bad, I think)
   
   Things are not this black and white. Just because I don't 
   have any services
   deployed that depend on A does not mean that it should be 
   undeployed. The
   naming service is a perfect example. Just because I don't 
   have any services
   deployed that depend on the naming service does not mean that 
   I don't have
   external clients using the naming service.
   
   
2. B depends on A. 

Re: [JBoss-dev] Jboss 2.4.1

[Scott M Stark]

Yes, those two jars were updated and the packages redone.

- Original Message - 
From: Julian Gosnell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 2:05 PM
Subject: Re: [JBoss-dev] Jboss 2.4.1


 Scott,
 
 Do you mean that you have edited the 2.4.1 release on SourceForge ?
 
 If so, I need to trash the 2.4.1/Jetty release I am doing and start aain
 on the new release.
 
 
 Thanks,
 
 
 Jules
 
 
 Scott M Stark wrote:
 
  I synched up the jboss-j2ee.jar from client and lib with the jboss-j2ee
  module
  and repackaged the 2.4.1 release bundles.
 
  - Original Message -
  From: Vincent Harcq [EMAIL PROTECTED]
  To: Dev JBoss [EMAIL PROTECTED]
  Sent: Monday, September 10, 2001 1:27 AM
  Subject: [JBoss-dev] Jboss 2.4.1
 
   Hi,
   Under branch 2.4.1.
   jboss-j2ee.jar in src/client and src/lib are not the same, the one in
  client
   does not contain EJB 2.0 classes.
   Regards.
   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
 
 
 _
 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

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Jason Dillon]

 We need to agree on and formalize our logging convention and then move to it.

Let us do this.  Logging is a critical system.

What is left to decide?

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RE: Jboss-development digest, Vol 1 #1425 - 16 msgs

[Jason Dillon]

 javax.xml.parsers.FactoryConfigurationError:
 org.apache.crimson.jaxp.SAXParserFactoryImpl
   at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:84)
   at
 org.apache.tools.ant.ProjectHelper.getParserFactory(ProjectHelper.java:780)
   at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:105)
   at
 org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:85)
   at org.apache.tools.ant.Main.runBuild(Main.java:439)
   at org.apache.tools.ant.Main.start(Main.java:153)
   at org.apache.tools.ant.Main.main(Main.java:176)

 Total time: 3 seconds
 org.apache.crimson.jaxp.SAXParserFactoryImpl

 Does anyone know what the cause/fix of this is?

Looks like Ant does not like 'org.apache.crimson.jaxp.SAXParserFactoryImpl'
for some reason.  Can you run with -debug and see if it gives you more
information?  This stack trace/error message is mostly useless.

Do you have JAXP, JAXP_DOM_FACTORY or JAXP_SAX_FACTORY set in your
environment?

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Scott M Stark]

- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 2:41 PM
Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?


 Are we still planning on dropping the older Log  Logger stuff in favor of
 Log4j?  If so, lets replace Logger with a new class that extends from
 Category, and provides Logger create() methods to access an instance.  It
 would have the trace() and isTraceEnabled().

Yes that is the plan but this is what I want agreement on.

 Trace seems to be best suited for detailed debug messages, which are only
 enabled for tracking down server internals.  In most cases I would like to
 run JBoss with debug enabled, but I don't want to get flooded with tons of
 messages.

 IMHO, debug messages should provide adequte brief information, which could
 be used to track down a problem, and trace is used to provide as much
 information as possible.

This is my view of logging as well.

 --jason


 On Mon, 10 Sep 2001, Scott M Stark wrote:

  Yes, there is an example in the default log4j.properties file that is
  commented
  out. Simply uncomment the last line as follows:
 
  # An example of enabling the custom TRACE level priority that is used
  # by the JBoss internals to diagnose low level details. This example
  # turns on TRACE level msgs for the org.jboss.ejb.plugins package and
its
  # subpackages. This will produce A LOT of logging output.
 
log4j.category.org.jboss.ejb.plugins=TRACE#org.jboss.logging.log4j.TracePrio
  rity
 
  If you now invoke an ejb method you will see a large number of messages
  detailing
  the activity of the Entity instance locking for example(provided that
was
  not dropped
  in the RH changes).
 
  Before rushing off to switch to using this custom priority however, I
would
  like
  to have an agreement that is the best way to do this.
 
  - Original Message -
  From: David Jencks [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Monday, September 10, 2001 12:54 PM
  Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?
 
 
   Hi,
   So far I have been unsuccessful in turning on the TRACE priority --
thus
   the excessive DEBUG stuff I have been using.  Do you have an example
of
  how
   to turn it on?  If I can get it to work I will happily turn most of my
   debugs into traces.
  
   Thanks
   david jencks
  
   On 2001.09.10 15:12:06 -0400 Scott M Stark wrote:
Ok. Just moving to log4j to avoid deprecation warning is not worth
the
effort as we need to define a logging usage pattern and then move to
it.
One big issue we have right now is that debug msgs are anything from
verbose one-time initialization mgs to per method traces of
activity.
  The
server.log is inundated with output when any type of client
throughput
is seen. For example, running the testsuite produces a 3Mb log file
in
9 minutes.
   
I added a custom TRACE priority to allow finer granularity of
debugging
msgs. The notion is that TRACE level msgs are those that are issued
as a
result of some request while DEBUG msgs are not. We need to agree on
and formalize our logging convention and then move to it.
   
 
 
 
  ___
  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] log4j switchover - anyone working on this?

[Scott M Stark]

I think just the custom logging class that replaces the existing Log, Logger
and
JBossCategory and the use of TRACE. I'm in agreement with you on this
items so unless there is other input to the contrary the details of the new
Logger or
whatever is all that remains. Due to the proposed change to have a Logger
class in
log4j we probably don't want to use Logger as a classname to minmize name
clash issues.

- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 2:45 PM
Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?


  We need to agree on and formalize our logging convention and then move
to it.

 Let us do this.  Logging is a critical system.

 What is left to decide?

 --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: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?

[Jason Dillon]

 Or even better, as Jason Dillon points out, does it provide an abstracted
 interface with the above features that JG can plug into?  Sacha and I have
 developed our own abstraction interface, but maybe JINI provides a better
 one.  I personally know jack squat about JINI and should really read up on
 it if it really is a viable solution. Or is it just vaporware, or
 prototypeware.

I am in the opposite situation, and I know squat about JavaGroups.  I would
really suggest reading over the basics of JINI.  It does not provide some of
the features of JG that you mentioned (which sound nice), but does provide
features which JG does not have (leasing is one big one).

From my limited knowledge of JG  somewhat limited knowledge about JINI, I
think that it is possible to plug JG into JINI, or rather register a JG
service with the JINI lookup service.

This way we get the best of both worlds.

Jini in a Nutshell (o'rielly) is a nice concise overview of Jini.  I found
it very informative, for what that is worth.  I do not think that Jini is
vaporware, rather it may just become the dominate platform for writing
distributed applications in Java...

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] exposing boot sequence richer xml config

[Jason Dillon]

 I'm still confused about what you are trying to accomplish here.  I would
 really appreciate it if you could take a few minutes and write down,
 without specifying a notation, the sequence of events you are trying to
 control and the variation points along that sequence.

Sure.  There are three major reason why I am moving in this direction.

 1) Expose as much configuration to integrators as possible, with out
complicating the system for users who do not need to muck with the
boot config.

 2) Setup logging as soon as possible.

 3) Provide a richer configuration lanugage.

I do not expect most users/integrators to change the sequence, but I do
expect that they might want to tweak some parameters.

What I suggest will provide a definitive configuration file for the server,
not just the service which are running inside.

I personally have not made use of the JBoss distribution layout, ever.  It
has never fit in with my deployment scheme.  I spent a few weeks writing a
jython/ant based system which handles setting up the environment that JBoss
expects from my layout.  I have heard others with the same problem, trying
to get it read files from somewhere other than conf/xxx/** and the like.

There is no reason why we need to be strict when it comes to where these
files live, or how users tell JBoss where to find them.

Does that help, or have I just clouded the issue more?

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Mbean package deployment and undeployment

[Scott M Stark]

Let's get both approaches working as it remains to be seen if the complexity
of
the recursive/implicit stuff is worth the trouble.

- Original Message -
From: David Maplesden [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 2:31 PM
Subject: RE: [JBoss-dev] Mbean package deployment and undeployment


 OK, thats good, I wanted your nod before committing, which I will do some
 time today.

 My stuff doesn't break the current startup and I have made a few changes
to
 the startup configuration so that it all works nicely.  However I will
need
 you to look over the changes and check I haven't stuffed up any of your
nice
 recursive deploy/undeployment things.

  -Original Message-
  From: David Jencks [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, September 11, 2001 9:35 AM
  To: [EMAIL PROTECTED]
  Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
 
 
  Well,
  after struggling to get a working jboss startup using only
  the recursive
  dependencies, I am inclined to agree with you that relying
  solely on them
  is not necessarily appropriate.  I don't know a good final answer:
 
  --recursive deployment is nice because it lets you aggregate chunks of
  deployment at many levels, and only explicitly deploy the top level.
 
  --mbean dependencies are nice because often you don't care
  where the code
  /configuration for the service is, you just need to make sure
  it's there.
 
  I'd say, if your stuff doesn't break the current startup, or
  you have a
  modified startup that works, and you have (or plan to have)
  at least some
  minimal tests, commit it.  I'd like to see it and make the
  explicit/implicit deployment/undeployment on top of it.  We
  can work out
  the best balance between the actual use of the two schemes by
  experiment
  and discussion.
 
  Thanks
  Cant wait!
  david jencks
 
  On 2001.09.10 16:47:32 -0400 David Maplesden wrote:
   Time for my two cents...
  
   I have just finished incorporating my scheme (the use of the depends
   elements) with David J's and it seems to work for the
  simple examples I
   have
   tested it on.  I am a bit unsure whether or not to commit
  the changes
   (after
   more testing) though because the two schemes don't mesh
  particularly well
   in
   the source.  Some odd behaviour would be possible if
  deployments attempt
   to
   use both mechanisms at the same time.
  
   In my opinion some of the problems or discussion points
  that are coming
   up
   in this thread are because the recursive deployment model
  is not always
   suitable, when all you want to do is specify a simple
  dependency.  The
   naming service (JNDI) is a classic example, where many of the other
   services
   need this service to be started before they will
  successfully start but
   it
   is easy to deploy on its own.
  
   The recursive deployment mechanism I feel is excellent for
  deploying and
   undeploying applications that are spread across multiple sar's and
   comprise
   multiple mbean services.  I don't think it is so effective
  at specifying
   simple dependencies between services, especially the core
  ones that exist
   during the startup process.
  
   David
  
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 11, 2001 8:42 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Mbean package deployment and undeployment
   
   
   
 On 2001.09.10 15:39:58 -0400 Scott M Stark wrote:
  For the jbossmq-service.xml example, does reploying
jbossmq-service.xml
  cause
  jboss-service.xml to be undeployed and redeployed?

 No, jboss-service.xml is not listed as a dependency of
jbossmq-service.xml.
But JBossMQ requires that a JNDI naming service be present,
so how is that
dependency specified? Also in the future I want to make
better use of the
JBossSX framework for authentication and authorization in
  other JBoss
services
to avoid the passwords spread all over the place
configuration issue we
now
have so this is another future core service dependency.
   
 
  Likewise, would just undeploying jbossmq-service.xml undeploy
  jboss-service.xml?

 In the current situation, as just noted, no.  Hmmm. If it
was listed, I
 think it would undeploy, which seems like a bad idea.

 What would be the desirable behavior in these scenarios?

 1. B and C both depend on A. B and C are explicitly
deployed, causing A to
 be recursively deployed.  B is undeployed.  What happens?
 - A remains deployed, since C is still depending on it.
(good, I think)
 - A is undeployed, causing C to be undeployed. (bad, I think)

A should remain deployed.
   
 assuming A remains deployed, then undeploy C
 - A is now undeployed, since nothing depends on it and
  it was not
 explicitly deployed. (good, I think)
 - A remains 

Re: [JBoss-dev] Build Problems

[Andreas Schaefer]

- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 2:43 PM
Subject: Re: [JBoss-dev] Build Problems


  jboss-all:
 
  - I can't compile Jetty to get the webserver running

 I am not sure this really works yet.  I had to use the 2.4.x/Jetty package
 to test the website deployment.

Can you tell how you did it ?

  jboss-website:
 
  - Whatever I build the manual is builded but not the website

 Could you explain this in more detail; I don't understand the problem your
 are having.

Ups, sorry, my fault. I was only looking at the build/output directory. Now
I found it.

Andy


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] exposing boot sequence richer xml config

[Jason Dillon]

 Couldn't you also define classloaders here for the Security Manager?

Sure, though I would defer all security bits to Scott.

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Jason Dillon]

 I think just the custom logging class that replaces the existing Log, Logger
 and
 JBossCategory and the use of TRACE. I'm in agreement with you on this
 items so unless there is other input to the contrary the details of the new
 Logger or
 whatever is all that remains.

What about the current Log.setLog() stuff?  Will that go away?  It was one
of the priary reasons that I did not convert some components to Log4j.

 Due to the proposed change to have a Logger class in
 log4j we probably don't want to use Logger as a classname to minmize name
 clash issues.

There is no reason why we can not use Logger, I would not suggest anything
else.  There will be almost no reasons to import org.jboss.log.Logger and
org.apache.log4j.Logger, we will simply use our version.  Applications can
choose which they prefer and use it.

Only our Logger impl will have to worry about the Log4j Logger, but simply
put:

public class Logger
extends org.apache.log4j.Logger
{
   // ...
}

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?

[Bill Burke]

I started to read the JINI spec.  Pretty cool stuff. The leasing interface
is also very interesting.  Sacha and I are pretty close to having HA JNDI,
HA SLSBs, and HA EBs hooked into javagroups.  We'll probably just iterate
and look into JINI later.

Bill


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
 Dillon
 Sent: Monday, September 10, 2001 6:10 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?


  Or even better, as Jason Dillon points out, does it provide an
 abstracted
  interface with the above features that JG can plug into?  Sacha
 and I have
  developed our own abstraction interface, but maybe JINI
 provides a better
  one.  I personally know jack squat about JINI and should really
 read up on
  it if it really is a viable solution. Or is it just vaporware, or
  prototypeware.

 I am in the opposite situation, and I know squat about
 JavaGroups.  I would
 really suggest reading over the basics of JINI.  It does not
 provide some of
 the features of JG that you mentioned (which sound nice), but does provide
 features which JG does not have (leasing is one big one).

 From my limited knowledge of JG  somewhat limited knowledge about JINI, I
 think that it is possible to plug JG into JINI, or rather register a JG
 service with the JINI lookup service.

 This way we get the best of both worlds.

 Jini in a Nutshell (o'rielly) is a nice concise overview of Jini.  I found
 it very informative, for what that is worth.  I do not think that Jini is
 vaporware, rather it may just become the dominate platform for writing
 distributed applications in Java...

 --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: [JBoss-dev] message redelivery MDB TX timeout with NotSupported

[Jason Dillon]

 Hi I thought of an Idea that should fix Jason's problem while not chaning
 the current MDB invoker too much.  What we have to do is get rid of that
 ugly timeout.  So when MDB TX is NotSupported, lets not elist the TX with
 the TM since he sill timeout the transaction.  Lets just manually
 commit/rollback the TX via the sessions's XAResource.

Can you do that?  That sounds like a simple solution.

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] exposing boot sequence richer xml config

[Bill Burke]

I'd like to see substitution variables in jboss.jcml so that you can use
environment variables to get at some of the hardcoded paths that need to be
set up in config

BIll

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of David
 Jencks
 Sent: Monday, September 10, 2001 7:10 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] exposing boot sequence  richer xml config


 Thanks jason, now I have more questions ;-)

 On 2001.09.10 18:00:53 -0400 Jason Dillon wrote:
   I'm still confused about what you are trying to accomplish here.  I
  would
   really appreciate it if you could take a few minutes and write down,
   without specifying a notation, the sequence of events you are
 trying to
   control and the variation points along that sequence.
 
  Sure.  There are three major reason why I am moving in this direction.
 
   1) Expose as much configuration to integrators as possible, with out
  complicating the system for users who do not need to muck with the
  boot config.

 Right now with rh, you can specify all the directories you need (and some
 you probably don't) as urls on the command line (as I understand what is
 happening).  What specific aspects of the boot configuration do
 you want to
 change other than this?
 
   2) Setup logging as soon as possible.
 This is obviously a good idea, I'm not sure how much sooner it can get if
 its run through an mbean and loaded with a recyclable classloader.

 
   3) Provide a richer configuration lanugage.
 This seems like a very separate question to me.  I've seen some discussion
 about being able to call arbitrary mbean methods during the startup
 sequence, but haven't seen a convincing example of why setting properties,
 calling init, and calling start isn't sufficient.  Given a 3rd party mbean
 I would think one could wrap it in a jboss service mbean where
 the init and
 start methods called the appropriate 3rd party methods.  I'm,
 well, nervous
 about making it easy to call arbitrary mbean methods on startup.  Is there
 an actual example of this being required?

 
  I do not expect most users/integrators to change the sequence, but I do
  expect that they might want to tweak some parameters.
 
  What I suggest will provide a definitive configuration file for the
  server,
  not just the service which are running inside.

 I remain less than convinced that it is a good idea to put startup
 configuration info (where the directories are, mostly, as I understand it)
 and mbean configuration info in the same file.  If the current
 *service.xml
 format is maintained, it is possible to compose more and more large-scale
 configuration sets out of different sized chunks.  If you put other
 configuration info in one of these, that one cannot be used as a
 chunk-- it
 is forced to be top level.
 
  I personally have not made use of the JBoss distribution layout, ever.
  It
  has never fit in with my deployment scheme.

 Is this still so true with the new web-deploy stuff from marc?

 I spent a few weeks writing
  a
  jython/ant based system which handles setting up the environment that
  JBoss
  expects from my layout.  I have heard others with the same problem,
  trying
  to get it read files from somewhere other than conf/xxx/** and the like.
 
  There is no reason why we need to be strict when it comes to where these
  files live, or how users tell JBoss where to find them.

 Allowing any location is good, and I think implemented.  What advantage
 does an xml file have over the command line for describing location?


 Hope this isn't nitpicking or too many questions-- I really want to
 understand what you have in mind.

 thanks
 david jencks
 
  Does that help, or have I just clouded the issue more?
 
  --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




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Scott M Stark]

Because I don't want redundant interfaces to the logging system.

- Original Message - 
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 4:14 PM
Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?


 What is wrong with rewriting all code using Log and Logger to use
 JBossCategory instead?  It's easy and often you can improve things by eg
 category.error(message, exception)
 
 what am I missing here?
 david jencks
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[Hiram Chirino]

From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?
Date: Mon, 10 Sep 2001 14:41:20 -0700 (PDT)

Are we still planning on dropping the older Log  Logger stuff in favor of
Log4j?  If so, lets replace Logger with a new class that extends from
Category, and provides Logger create() methods to access an instance.  It
would have the trace() and isTraceEnabled().


If going with this approach, just a isTraceEnabled public variable so that 
you don't incure the cost of a method call. (since you'll be doing the check 
to avoid the cost a trace method call in the first place.)

Regards,
Hiram


_
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] exposing boot sequence richer xml config

[Jason Dillon]

   1) Expose as much configuration to integrators as possible, with out
  complicating the system for users who do not need to muck with the
  boot config.

 Right now with rh, you can specify all the directories you need (and some
 you probably don't) as urls on the command line (as I understand what is
 happening).  What specific aspects of the boot configuration do you want to
 change other than this?

This is just not true.  RH/Main will take one URL and a patch directory,
then generate the other locations from the URL and setup jboss.home based on
where run.jar lives.

We are expecting configuration files to be under the given url/conf/config,
which is unneeded.

   2) Setup logging as soon as possible.
 This is obviously a good idea, I'm not sure how much sooner it can get if
 its run through an mbean and loaded with a recyclable classloader.

We already setup logging really soon, but we don't expose the configuration
of the logging service... which is bad.

  I do not expect most users/integrators to change the sequence, but I do
  expect that they might want to tweak some parameters.
 
  What I suggest will provide a definitive configuration file for the
  server,
  not just the service which are running inside.

 I remain less than convinced that it is a good idea to put startup
 configuration info (where the directories are, mostly, as I understand it)
 and mbean configuration info in the same file.  If the current *service.xml
 format is maintained, it is possible to compose more and more large-scale
 configuration sets out of different sized chunks.  If you put other
 configuration info in one of these, that one cannot be used as a chunk-- it
 is forced to be top level.

What?  I am talking about the configuration file for booting the server.
This does not fall over into service.xml files at all.  I want to control
how JBoss boots with out having to write/maintain my own version of Main or
a custom boot system.

The current system makes many assumptions about how the configuration of the
system will be laid out, which is not a good idea.

I am talking about exposing this configuration, for users who need it,
allowing it to be omitted (by using defaults) for those who don't.

  I personally have not made use of the JBoss distribution layout, ever.
  It
  has never fit in with my deployment scheme.

 Is this still so true with the new web-deploy stuff from marc?

Even more so.  The current system that I use must be scrapped to make use of
the new stuff.  Which might be a good idea any ways, but if I do that I don't
want to be forced to use the conf/configname/... semantics.  I would
rather specify a URL with ?params which would be served up by a JSP.

 I spent a few weeks writing
  a
  jython/ant based system which handles setting up the environment that
  JBoss
  expects from my layout.  I have heard others with the same problem,
  trying
  to get it read files from somewhere other than conf/xxx/** and the like.
 
  There is no reason why we need to be strict when it comes to where these
  files live, or how users tell JBoss where to find them.

 Allowing any location is good, and I think implemented.  What advantage
 does an xml file have over the command line for describing location?

This is not implemented... why do you think it is?

The command line is used to provide the initial URL and property overrides,
everything else is configured via the xml config file.

Currently, to use a set of configs you need to:

 ./run.sh --net-install http://configserver --configuration myconfig

What I suggest is that we replace this with:

 ./run.sh http://configserver/myconfig

or

 ./run.sh http://configserver?config=myconfig

or any other way you choose to implement the JSP/Servlet which serves up the
config.

If you need to specify other bits then you can use -Djboss.* to set more
properties.

By doing this it means that we need to provide a single file (xml) which
tells the boot system what todo.  I would like to figure out a way to make
the jboss-service.xml and this config live in the same file, so that we can
simplify configuration.

 Hope this isn't nitpicking or too many questions-- I really want to
 understand what you have in mind.

I really want you to understand too, so let me know how I can make it
clearer.

JBoss is a really powerful platform for running applications, lets make it
even more powerful by exposing the boot/configuration logic to allow
integrator's to adapt it to any environment.

We certainly can not foresee all of the uses of JBoss, but we can plan for
some unexpected use by exposing extra configuration.

Marc removed the boot.conf stuff to simplify the configuration and startup
logic.  I think that the previous boot stuff was confusing, but it was
flexible and allowed me get up and running quickly with the layout which I
am used to.

I want to keep this simple, but not so simple that it limits how people can
use it.  Simple may be the word, but flexible is the key.

RE: [JBoss-dev] exposing boot sequence richer xml config

[Jason Dillon]

 I'd like to see substitution variables in jboss.jcml so that you can use
 environment variables to get at some of the hardcoded paths that need to be
 set up in config

Environment variables or properties?

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: contrib/jetty/src/build build.xml

[Jules Gosnell]

  User: jules_gosnell
  Date: 01/09/10 16:52:05

  Modified:jetty/src/build build.xml
  Log:
  jetty repackaging and build script fixes
  
  Revision  ChangesPath
  1.13  +12 -9 contrib/jetty/src/build/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/contrib/jetty/src/build/build.xml,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- build.xml 2001/08/30 03:12:52 1.12
  +++ build.xml 2001/09/10 23:52:05 1.13
  @@ -1,5 +1,5 @@
   ?xml version=1.0?
  -!-- $Id: build.xml,v 1.12 2001/08/30 03:12:52 mnf999 Exp $ --
  +!-- $Id: build.xml,v 1.13 2001/09/10 23:52:05 jules_gosnell Exp $ --
   
   
   !-- === --
  @@ -20,7 +20,7 @@
   property name=build.dir value=${basedir}/build/
   property name=build.classes.dir value=${build.dir}/classes/
   
  -property name=classpath 
value=${lib.dir}/xml.jar;${jboss.home}/lib/jmxri.jar;${jboss.home}/lib/ext/log4j.jar;${jboss.home}/lib/ext/jboss.jar;${jboss.home}/lib/ext/ejb.jar;${build.classes.dir};${jetty.home}/lib/javax.servlet.jar;${jetty.home}/lib/org.apache.jasper.jar;${jetty.home}/lib/com.sun.net.ssl.jar;${jetty.home}/lib/com.mortbay.jetty.jar/
  +property name=classpath 
value=${lib.dir}/xml.jar;${jboss.home}/lib/jmxri.jar;${jboss.home}/lib/jboss-jaas.jar;${jboss.home}/lib/ext/log4j.jar;${jboss.home}/lib/ext/jboss.jar;${jboss.home}/lib/ext/ejb.jar;${build.classes.dir};${jetty.home}/lib/javax.servlet.jar;${jetty.home}/lib/org.apache.jasper.jar;${jetty.home}/lib/com.sun.net.ssl.jar;${jetty.home}/lib/org.mortbay.jetty.jar;${jetty.jmx}/lib/org.mortbay.jetty.jmx.jar/
   
property name=jar.file value=${name}.jar/
property name=test.client value=tomcat-test/
  @@ -29,6 +29,7 @@
   
   echo message=jboss.home=${jboss.home} /
   echo message=jetty.home=${jetty.home} /
  +echo message=jetty.jmx=${jetty.jmx} /
   echo message=classpath=${classpath} /
 /target
   
  @@ -38,7 +39,9 @@
 !-- === --
 target name=prepare depends=init
   mkdir dir=${build.dir}/
  +!--
   copy file=${src.resources}/jboss-web.dtd 
tofile=${build.classes.dir}/jboss-web.dtd/
  + --
 /target
   
   
  @@ -169,14 +172,14 @@
/fileset
   /copy
   
  -echo message=adding ${basedir}/etc/jetty.xml to ${cfg.tgt} /
  -copy todir=${cfg.tgt} file=${basedir}/etc/jetty.xml/
  -echo message=adding ${basedir}/jetty.properties to ${cfg.tgt} /
  -copy todir=${cfg.tgt} file=${basedir}/etc/jetty.properties/
  +echo message=adding ${basedir}/src/etc/jetty.xml to ${cfg.tgt} /
  +copy todir=${cfg.tgt} file=${basedir}/src/etc/jetty.xml/
  +echo message=adding ${basedir}/src/jetty.properties to ${cfg.tgt} /
  +copy todir=${cfg.tgt} file=${basedir}/src/etc/jetty.properties/
   echo message=installing README file /
  -copy todir=${dist.dir} file=${basedir}/etc/README/
  +copy todir=${dist.dir} file=${basedir}/src/etc/README/
   echo message=installing VERSION file /
  -copy todir=${dist.dir} file=${basedir}/etc/VERSION/
  +copy todir=${dist.dir} file=${basedir}/src/etc/VERSION/
   
 echo
   Adding Jetty MLET to jboss.conf
  @@ -233,7 +236,7 @@
 echo
   Adding run script
 /echo
  -   copy todir=${dist.dir} file=${basedir}/etc/run.sh/
  +   copy todir=${dist.dir} file=${basedir}/src/bin/run.sh/
  chmod file=${dist.dir}/run.sh perm=ugo+rx/
   
 /target
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] JNDI - Problem

[Jason Dillon]

What is trying to connect to 127.0.0.2 ?  Why is any machine configured to
use 127.0.0.2 as its ip addr?

--jason


On Mon, 10 Sep 2001, Andreas Schaefer wrote:

 Hi Geeks

 Maybe it is just me but I have a problem to access
 JBoss JNDI naming service from Windows to an
 Linux box but vice versa is working fine.
 Environment:
 - SuSE Linux 7.1, Kernel 2.4, IBM Java 2, JNDI naming bound to 1099,
   JBoss 2.4 with Jetty, EJB successfully deployed
 -Windows 2000, Java Version 1.3.1 and 1.4, Java application trying to access
   the deployed EJB on the remote server

 Any ideas ? - Andy

 That is the stack trace:
 JNDI Context properties:
 {java.naming.factory.initial=org.jnp.interfaces.NamingC
 ontextFactory, java.naming.provider.url=mpg-dev-2:1099,
 java.naming.factory.url.
 pkgs=org.jboss.naming:org.jnp.interfaces}
 javax.naming.CommunicationException.  Root exception is
 java.rmi.ConnectExceptio
 n: Connection refused to host: 127.0.0.2; nested exception is:
 java.net.ConnectException: Connection refused: connect
 at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
 at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source)
 at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)
 at sun.rmi.server.UnicastRef.invoke(Unknown Source)
 at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:349)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:333)
 at javax.naming.InitialContext.lookup(Unknown Source)
 at
 org.jboss.connector.ejb.EJBConnector.getAdaptorBean(EJBConnector.java
 :177)
 at
 org.jboss.connector.ejb.EJBConnector.init(EJBConnector.java:127)
 at
 org.jboss.connector.ejb.EJBConnector.init(EJBConnector.java:113)
 at test.jboss.jmx.TestClient.init(TestClient.java:80)
 at test.jboss.jmx.TestClient$1.run(TestClient.java:62)
 at java.security.AccessController.doPrivileged(Native Method)
 at test.jboss.jmx.TestClient.main(TestClient.java:59)
 Caused by: java.net.ConnectException: Connection refused: connect
 at java.net.PlainSocketImpl.socketConnect(Native Method)
 at java.net.PlainSocketImpl.doConnect(Unknown Source)
 at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
 at java.net.PlainSocketImpl.connect(Unknown Source)
 at java.net.Socket.connect(Unknown Source)
 at java.net.Socket.connect(Unknown Source)
 at java.net.Socket.init(Unknown Source)
 at java.net.Socket.init(Unknown Source)
 at
 sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown S
 ource)
 at
 sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown S
 ource)
 ... 15 more


 ___
 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] JNDI - Problem

[Andreas Schaefer]

Good question, I have no idea.

Strange is that local lookups from the Linux server are
working fine, too. Only when W2K tries to make the
lookup it fails this way. I will try to make the lookup
from another Linux box.

Andy

- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, September 10, 2001 5:31 PM
Subject: Re: [JBoss-dev] JNDI - Problem


 What is trying to connect to 127.0.0.2 ?  Why is any machine configured to
 use 127.0.0.2 as its ip addr?

 --jason



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: tools/bin ant

[Jason Dillon]

  User: user57  
  Date: 01/09/10 18:07:18

  Modified:bin  ant
  Log:
   o updating to ant v1.4
   o ANT_OPTS has been moved closer to class name (like the dist version)
   o added JAVA_OPTS to replace it, though current usage of ANT_OPTS should
 still work
  
  Revision  ChangesPath
  1.5   +1 -1  tools/bin/ant
  
  Index: ant
  ===
  RCS file: /cvsroot/jboss/tools/bin/ant,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ant   2001/09/01 08:31:01 1.4
  +++ ant   2001/09/11 01:07:18 1.5
  @@ -136,4 +136,4 @@
   echo ANT_OPTS = $ANT_OPTS
   fi
   
  -$JAVACMD $ANT_OPTS -classpath $LOCALCLASSPATH -Dant.home=${ANT_HOME} 
org.apache.tools.ant.Main $@
  +$JAVACMD $JAVA_OPTS -classpath $LOCALCLASSPATH -Dant.home=${ANT_HOME} $ANT_OPTS 
org.apache.tools.ant.Main $@
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: tools/lib ant.jar optional.jar

[Jason Dillon]

  User: user57  
  Date: 01/09/10 18:07:19

  Modified:lib  ant.jar optional.jar
  Log:
   o updating to ant v1.4
   o ANT_OPTS has been moved closer to class name (like the dist version)
   o added JAVA_OPTS to replace it, though current usage of ANT_OPTS should
 still work
  
  Revision  ChangesPath
  1.2   +465 -471  tools/lib/ant.jar
  
Binary file
  
  
  1.2   +479 -431  tools/lib/optional.jar
  
Binary file
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] JBoss MS SQL Server 2000

[Yong T. Kim]

Okay, I understand now... It was very clear 
answer. Thanx. ;-)

- kimion -

  - Original Message - 
  From: 
  David Maplesden 
  To: '[EMAIL PROTECTED]' 
  
  Sent: Monday, September 10, 2001 9:35 
  PM
  Subject: RE: [JBoss-dev] JBoss  MS 
  SQL Server 2000
  
  I 
  think you are getting this because you are attempting to accessthe 
  DataSource from outside of JBoss. DataSources can only be accessed from 
  code running in the same JVM as the DataSource i.e. from within ejb's or 
  mbean's deployed by JBoss. Separately running clients cannot access the 
  DataSource's. 
  
  So 
  the code you have below (using "java:/SQLServerPool") should work from within 
  JBoss not from another JVM.
  
  Does 
  this help?
  
  Cheers,
  David
  
-Original Message-From: Yong T. Kim 
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, September 11, 2001 1:28 
PMTo: [EMAIL PROTECTED]Subject: 
[JBoss-dev] JBoss  MS SQL Server 2000
I think I have successfully created a 
connection pool for MS SQL 2000... but I can't connect to it from my test 
client code...

When JBoss starts up, I get output like 
below...
[XADataSourceLoader] 
Starting 

[SQLServerPool] XA Connection pool 
SQLServerPool bound to java:/SQLServerPool
[XADataSourceLoader] Started

It seems like JBoss was able to create the 
connection pool successfully...

However, when I run my client code below, I get 
an error message saying, "javax.naming.NameNotFoundException: SQLServerPool 
not bound at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown 
Source) at 
sun.rmi.transport.StreamRemoteCall.executeCall(Unknown 
Source) at 
sun.rmi.server.UnicastRef.invoke(Unknown 
Source) at 
org.jnp.server.NamingServer_Stub.lookup(Unknown 
Source) at 
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:349) 
at 
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:333) 
at javax.naming.InitialContext.lookup(Unknown 
Source) at 
DataSourceTest.main(DataSourceTest.java:37)"

What am I doing wrong?

Here is the sample code...

 
env.put(Context.INITIAL_CONTEXT_FACTORY, 
"org.jnp.interfaces.NamingContextFactory"); 
env.put(Context.PROVIDER_URL, 
"localhost:1099"); 
javax.naming.Context ctx = new 
InitialContext(env); 
DataSource ds = (DataSource) ctx.lookup("SQLServerPool"); // I tried with 
java:/SQLServerPool, still didn't 
work 
Connection con = ds.getConnection();

Can someone help?

Thanks, in advance...

Yong T. Kim 
(kimion.com)Software Developer[EMAIL PROTECTED]http://www.kimion.com:8080

RE: [JBoss-dev] exposing boot sequence richer xml config

[Bill Burke]

Yeah, sorry, properties


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram
 Chirino
 Sent: Monday, September 10, 2001 10:15 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] exposing boot sequence  richer xml config



 I like properties.

 From: Jason Dillon [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] exposing boot sequence  richer xml config
 Date: Mon, 10 Sep 2001 16:52:29 -0700 (PDT)
 
   I'd like to see substitution variables in jboss.jcml so that
 you can use
   environment variables to get at some of the hardcoded paths
 that need to
 be
   set up in config
 
 Environment variables or properties?
 
 --jason
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development


 _
 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




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Automated JBoss Testsuite Results

[chris]

JBoss daily test results

SUMMARY

Number of tests run:   223



Successful tests:  99

Errors:87

Failures:  37





[time of test: 11 September 2001 3:27 GMT]
[java.version: 1.3.0]
[java.vendor: IBM Corporation]
[java.vm.version: 1.3.0]
[java.vm.name: Classic VM]
[java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)]
[os.name: Linux]
[os.arch: x86]
[os.version: 2.4.3-12]

See http://lubega.com for full details

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS

[details not shown - as this makes the mail too big to reach the sf mailing list]



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] exposing boot sequence richer xml config

[Hiram Chirino]

I like properties.

From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] exposing boot sequence  richer xml config
Date: Mon, 10 Sep 2001 16:52:29 -0700 (PDT)

  I'd like to see substitution variables in jboss.jcml so that you can use
  environment variables to get at some of the hardcoded paths that need to 
be
  set up in config

Environment variables or properties?

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


_
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] log4j switchover - anyone working on this?

[Hiram Chirino]

Forgive the ignorance, I spoke without a full understanding of how log4j 
works..

Regards,
HIram

From: Scott M Stark [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?
Date: Mon, 10 Sep 2001 17:33:00 -0700

This can't be done as wether or not the priority is enabled is a dynamic
function of
the category heirchary and a method call must be made to query. Walk 
through
a JMS msg delivery or EJB method invocation and count the method calls and
then come back and tell me this amounts to even .01% of the total.

 
  If going with this approach, just a isTraceEnabled public variable so 
that
  you don't incure the cost of a method call. (since you'll be doing the
check
  to avoid the cost a trace method call in the first place.)
 
  Regards,
  Hiram
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


_
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

[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment AutoDeployer.java

[David Maplesden]

  User: dmaplesden
  Date: 01/09/10 19:45:46

  Modified:src/main/org/jboss/deployment AutoDeployer.java
  Log:
  Altered so that the AutoDeployer can be deployed before the individual deployers it 
uses.
  
  Revision  ChangesPath
  1.3   +90 -19jboss/src/main/org/jboss/deployment/AutoDeployer.java
  
  Index: AutoDeployer.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/AutoDeployer.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- AutoDeployer.java 2001/09/08 17:08:32 1.2
  +++ AutoDeployer.java 2001/09/11 02:45:45 1.3
  @@ -24,6 +24,10 @@
   import javax.management.ReflectionException;
   import javax.management.RuntimeErrorException;
   import javax.management.RuntimeMBeanException;
  +import javax.management.InstanceNotFoundException;
  +import javax.management.NotificationListener;
  +import javax.management.Notification;
  +import javax.management.MBeanServerNotification;
   import org.jboss.logging.log4j.JBossCategory;
   
   import org.jboss.system.ServiceMBeanSupport;
  @@ -40,19 +44,29 @@
* that directory will be watched separately. p
*
* When a file is to be deployed, the AutoDeployer will use the configured
  - * deployer to deploy it.
  + * deployer to deploy it. p
*
  + * If a given deployer mbean does not exist at startup, files for that deployer
  + * will not be deployed until that deployer does exist (is registered with main
  + * MBeanServer).
  + *
* @see org.jboss.deployment.J2eeDeployer
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Toby Allsopp/a
  - * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
  - * @version $Revision: 1.2 $
  + * @author a href=mailto:[EMAIL PROTECTED];David Maplesden/a
  + * @version $Revision: 1.3 $
*/
   public class AutoDeployer
  extends ServiceMBeanSupport
  -   implements AutoDeployerMBean, Runnable
  +   implements AutoDeployerMBean, NotificationListener,Runnable
   {
  +   // Constants -
  +   // Attributes 
   
  +   /** Instance logger. */
  +   private JBossCategory log = (JBossCategory)
  +  JBossCategory.getInstance(this.getClass());
  +   
  /**
   * Callback to the JMX agent.
   */
  @@ -103,18 +117,7 @@
   * and which should be ignored.
   */
  FilenameFilter[] deployableFilters;
  -   // Constants -
   
  -   // Attributes 
  -
  -   /**
  -* Instance logger.
  -*/
  -   private JBossCategory log = (JBossCategory)
  - JBossCategory.getInstance(this.getClass());
  -
  -   // = null;
  -
  // Static 
   
  // Constructors --
  @@ -395,6 +398,12 @@
 }
  };
}
  + catch (InstanceNotFoundException e)
  + {
  +log.info(Deployer ' + deployerNames[i] + ' isn't yet registered  +
  +files for this deployer will not be deployed until it is 
deployed.);
  +deployableFilters[i] = null;
  + }
 }
   
 StringTokenizer urls = new StringTokenizer(urlList, ,);
  @@ -475,6 +484,11 @@
}
 }
   
  +  // listen for the deployers to be deployed or undeployed
  +  // has to be done before the pre-deploy below so that deployers deployed 
  +  // during the pre-deploy are not missed.
  +  server.addNotificationListener(new 
ObjectName(JMImplementation:type=MBeanServerDelegate),this,null,null);
  +
 // Pre-deploy. This is done so that deployments available
 // on start of container is deployed ASAP
 run();
  @@ -482,8 +496,65 @@
 // Start auto deploy thread
 running = true;
 new Thread(this, AutoDeployer).start();
  +  
  }
   
  +   public void handleNotification(Notification notification, Object handback)
  +   {
  +  String type = notification.getType();
  +  if(type.equals(MBeanServerNotification.REGISTRATION_NOTIFICATION))
  +  {
  + ObjectName mbean = ((MBeanServerNotification)notification).getMBeanName();
  + 
  + log.debug(Received notification of mbean +mbean+'s deployment.);
  + 
  + for(int i=0; ideployerNames.length; i++)
  + {
  +if(deployerNames[i].equals(mbean))
  +{
  +   log.info(Deployer ' + deployerNames[i] + ' deployed,  +
  +   now available for deployments.);
  +   try
  +   {
  +  deployableFilters[i] = (FilenameFilter) server.invoke(
  + 

[JBoss-dev] CVS update: jboss/src/main/org/jboss/jmx/META-INF jboss-service.xml

[David Maplesden]

  User: dmaplesden
  Date: 01/09/10 19:46:57

  Modified:src/main/org/jboss/jmx/META-INF jboss-service.xml
  Log:
  Altered configuration to work with new deployment mechanism
  
  Revision  ChangesPath
  1.2   +3 -0  jboss/src/main/org/jboss/jmx/META-INF/jboss-service.xml
  
  Index: jboss-service.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jmx/META-INF/jboss-service.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jboss-service.xml 2001/08/29 23:36:50 1.1
  +++ jboss-service.xml 2001/09/11 02:46:57 1.2
  @@ -6,6 +6,9 @@
--
   
   server
  +
  +  dependsJBOSS-SYSTEM:service=Naming/depends
  +
 mbean code=org.jboss.jmx.server.JMXAdaptorService
 name=JMX:name=Adaptor,type=RMI/
   
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment ServiceDeployer.java

[David Maplesden]

  User: dmaplesden
  Date: 01/09/10 19:46:13

  Modified:src/main/org/jboss/deployment ServiceDeployer.java
  Log:
  Added support for depends elements in service.xml files.
  
  Revision  ChangesPath
  1.6   +245 -45   jboss/src/main/org/jboss/deployment/ServiceDeployer.java
  
  Index: ServiceDeployer.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/ServiceDeployer.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ServiceDeployer.java  2001/09/09 05:40:47 1.5
  +++ ServiceDeployer.java  2001/09/11 02:46:13 1.6
  @@ -17,6 +17,8 @@
   import java.net.MalformedURLException;
   import java.net.URL;
   import java.util.ArrayList;
  +import java.util.LinkedList;
  +
   import java.util.Collections;
   import java.util.HashMap;
   import java.util.HashSet;
  @@ -58,13 +60,22 @@
*
* @see   org.jboss.system.Service
* @authora href=mailto:[EMAIL PROTECTED];Marc Fleury/a
  + * @author a href=mailto:[EMAIL PROTECTED];David Maplesden/a
* @authora href=[EMAIL PROTECTED]David Jencks/a
  - * @version   $Revision: 1.5 $ p
  + * @version   $Revision: 1.6 $ p
*
*  b20010830 marc fleury:/b
*  ulinitial import
*li
*  /ul
  + *  
  + *  pb20010905 david maplesden:/b
  + *  ul
  + *  liChanged deployment procedure to deploy all listed mbeans, then 
  + *  initialise them all before finally starting them all.  Changed services 
  + *  sets to lists to maintain ordering.
  + *  /ul
  + *
*  b20010908 david jencks/b
*  ol
*li fixed tabs to spaces and log4j logging. Made the urlToServiceSet
  @@ -72,6 +83,11 @@
*deploy. Made undeploy work, and implemented sar dependency management
*and recursive deploy/undeploy.
*  /ol
  + *  
  + *  pb20010907 david maplesden:/b
  + *  ul
  + *  liAdded support for depends tag
  + *  /ul
*
*/
   public class ServiceDeployer
  @@ -102,6 +118,16 @@
  //To keep track of services suspended when we undeploy a jsr
  private Map suspendedUrlDependencyMap;
   
  +
  +   // each url is associated with an xml document
  +   private Map urlToDocumentMap;
  +
  +   // each url specifies a number of services it is dependent on
  +   private Map urlToDependsSetMap;
  +
  +   // maps mbeans to the urls that are dependent on them.
  +   private Map mbeanToURLSetMap;
  +
  // JMX
  private MBeanServer server;
   
  @@ -177,27 +203,188 @@
   * @exception DeploymentExceptionThrown if the package could not be
   *  deployed.
   */
  -   public void deploy(String urlString)
  +   public void deploy(String url)
 throws MalformedURLException, IOException, DeploymentException
  {
   
  -  log.debug(deploying document  + urlString);
  +  log.debug(deploying document  + url);
   
  -  if (isDeployed(urlString))
  +  if (isDeployed(url))
 {
  - undeploy(urlString);
  - log.debug(undeployed previous version of document  + urlString);
  + undeploy(url);
  + log.debug(undeployed previous version of document  + url);
 }
   
  +  // The Document describing the service
  +  Document document = null;
  +
  +  /**
  +   * First register the classloaders for this deployment If it is a jsr, the
  +   * jsr points to itself If it is a something-service.xml then it looks for
  +   * classpathcodebasehttp://bla.com (or file://bla.com)/codebase
  +   * default is system library dir archivesbla.jar, bla2.jar, bla3.jar
  +   * /archiveswhere bla is relative to codebase/classpath
  +   */
  +
  +  // Support for the new packaged format
  +  try
  +  {
  + if (url.endsWith(.jsr)
  +|| url.endsWith(.sar))
  + {
  +//use java.net.URLClassLoader here
  +ClassLoader cl = new java.net.URLClassLoader(new URL[]{new URL(url)});
  +document = getDocument(META-INF/jboss-service.xml, cl);
  +log.debug(got document jboss-service.xml from cl);
  + }
  +
  + //no mbeans to deploy for jars
  + else if(url.endsWith(.jar)
  +   || url.endsWith(.zip))
  + {
  +document = null;
  + }
  +
  + // We can deploy bare xml files as well
  + else if (url.endsWith(service.xml))
  + {
  +document = getDocument(url, null);
  + }
  + else
  + {
  +throw new Exception(not a deployable file type);
  + }
  +
  +  }
  +  catch (Exception ignored)
  +  {
  + log.error(Problem deploying url  + url + , no valid service.xml file 
found., ignored);
  + throw new DeploymentException(No valid service.xml file found + 

[JBoss-dev] CVS update: jbosscx/src/resources/jca-sar/META-INF jboss-service.xml

[David Maplesden]

  User: dmaplesden
  Date: 01/09/10 19:48:21

  Modified:src/resources/jca-sar/META-INF jboss-service.xml
  Log:
  Altered configuration to work with new deployment mechanism
  
  Revision  ChangesPath
  1.2   +1 -18 jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml
  
  Index: jboss-service.xml
  ===
  RCS file: /cvsroot/jboss/jbosscx/src/resources/jca-sar/META-INF/jboss-service.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jboss-service.xml 2001/09/08 19:32:21 1.1
  +++ jboss-service.xml 2001/09/11 02:48:21 1.2
  @@ -7,7 +7,7 @@
   !--   --
   !-- = --
   
  -!-- $Id: jboss-service.xml,v 1.1 2001/09/08 19:32:21 d_jencks Exp $ --
  +!-- $Id: jboss-service.xml,v 1.2 2001/09/11 02:48:21 dmaplesden Exp $ --
   
   !-- 
  |  This contains configuration for the RARDeployer and the 
  @@ -76,23 +76,6 @@
 org.jboss.resource.connectionmanager.jboss.MinervaXACMFactory
   /attribute
   attribute name=Properties/attribute
  -  /mbean
  -
  -  !--  --
  -  !-- Auto deployment  --
  -  !--  --
  -
  -  mbean code=org.jboss.deployment.AutoDeployer name=JCA:service=AutoDeployer
  -attribute name=Deployers
  -  JCA:service=RARDeployer
  -/attribute
  -attribute name=URLs
  -  ../deploy/lib,
  -  ../deploy
  -/attribute
  -attribute name=Timeout
  -  3000
  -/attribute
 /mbean
   
   
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/etc/conf/default jms-service.xml jetty-service.xml j2eedeployment-service.xml core-service.xml mail-service.xml jboss-service.xml hsql-default-service.xml

[David Maplesden]

  User: dmaplesden
  Date: 01/09/10 19:48:05

  Modified:src/etc/conf/default mail-service.xml jboss-service.xml
hsql-default-service.xml
  Added:   src/etc/conf/default jms-service.xml jetty-service.xml
j2eedeployment-service.xml core-service.xml
  Log:
  Altered configuration to work with new deployment mechanism
  
  Revision  ChangesPath
  1.2   +4 -3  jboss/src/etc/conf/default/mail-service.xml
  
  Index: mail-service.xml
  ===
  RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/mail-service.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- mail-service.xml  2001/08/29 22:30:19 1.1
  +++ mail-service.xml  2001/09/11 02:48:05 1.2
  @@ -9,9 +9,10 @@
   
   server
   
  -
 classpath archives=mail.jar/
  -  
  +
  +  dependsJBOSS-SYSTEM:service=Naming/depends
  +
 !--  --
 !-- Mail Connection Factory  --
 !--  --
  @@ -23,4 +24,4 @@
   attribute name=Passwordpassword/attribute
 /mbean
   
  -/server
  \ No newline at end of file
  +/server
  
  
  
  1.10  +3 -256jboss/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.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jboss-service.xml 2001/09/08 19:32:23 1.9
  +++ jboss-service.xml 2001/09/11 02:48:05 1.10
  @@ -7,7 +7,7 @@
   !--   --
   !-- = --
   
  -!-- $Id: jboss-service.xml,v 1.9 2001/09/08 19:32:23 d_jencks Exp $ --
  +!-- $Id: jboss-service.xml,v 1.10 2001/09/11 02:48:05 dmaplesden Exp $ --
   
   !-- 
  |  This is where you can add and configure your MBeans.
  @@ -20,10 +20,8 @@
  |  the MBeans it depends on.
 --
   
  -
   server
   
  -
   !--
   
 The Classpath element is needed for http based installations 
  @@ -47,6 +45,7 @@
 hsql.jar, 
 hsql-plugin.jar,
 jaas.jar,
  +  javac.jar,
 JavaGroups.jar,
 javax.servlet.jar,
 javax-sasl.jar,
  @@ -73,190 +72,15 @@
 tyrex.jar,
 tyrex-tm-plugin.jar,
 xalan.jar/
  -  !--  --
  -  !-- Class Loading--
  -  !--  --
  -
  -  mbean code=org.jboss.web.WebService
  -  name=JBOSS-SYSTEM:service=Webserver
  -attribute name=Port8083/attribute
  -  /mbean
  -
  -
  -  !--  --
  -  !-- JNDI --
  -  !--  --
  -
  -  mbean code=org.jboss.naming.NamingService
  -  name=JBOSS-SYSTEM:service=Naming
  -attribute name=Port1099/attribute
  -  /mbean
  -  mbean code=org.jboss.naming.JNDIView 
  -  name=JBOSS-SYSTEM:service=JNDIView/
  -
  -
  -  !--  --
  -  !-- Transactions --
  -  !--  --
  -
  -  mbean code=org.jboss.tm.TransactionManagerService 
  -  name=JBOSS-SYSTEM:service=TransactionManager
  -attribute name=TransactionTimeout300/attribute
  -
  -!-- Use this attribute if you need to use a specific Xid
  - implementation
  -attribute name=XidClassNameoracle.jdbc.xa.OracleXid/attribute
  ---
  -  /mbean
  -
  -  !-- 
  - | Uncomment to use Tyrex (tyrex.exolab.org) transaction manager plugin
  - | instead of the org.jboss.tm.TransactionManagerService and comment out
  - | the TransactionManagerService above.
  - |
  -  mbean code=org.jboss.tm.plugins.tyrex.TransactionManagerService
  - name=JBOSS-SYSTEM:service=TransactionManager
  -attribute name=ConfigFileName../conf/default/domain.xml/attribute
  -  /mbean
  -  --
  -
  -  mbean code=org.jboss.tm.usertx.server.ClientUserTransactionService
  -  name=JBOSS-SYSTEM:service=ClientUserTransaction
  -  /mbean
  -
  -
  -  !--  --
  -  !-- Security --
  -  !--  --
  -
  -  !-- Uncomment to enable the sample 

[JBoss-dev] CVS update: build/jboss build.xml

[David Maplesden]

  User: dmaplesden
  Date: 01/09/10 19:48:32

  Modified:jbossbuild.xml
  Log:
  Altered configuration to work with new deployment mechanism
  
  Revision  ChangesPath
  1.19  +45 -5 build/jboss/build.xml
  
  Index: build.xml
  ===
  RCS file: /cvsroot/jboss/build/jboss/build.xml,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- build.xml 2001/09/09 05:40:47 1.18
  +++ build.xml 2001/09/11 02:48:32 1.19
  @@ -10,7 +10,7 @@
   !----
   !-- == --
   
  -!-- $Id: build.xml,v 1.18 2001/09/09 05:40:47 d_jencks Exp $ --
  +!-- $Id: build.xml,v 1.19 2001/09/11 02:48:32 dmaplesden Exp $ --
   
   project default=main name=JBoss/Build
   
  @@ -565,8 +565,43 @@
 /fileset
   /copy
   
  -!-- Copy the hsql defaultds service xml snippet  (deploy) --
  -copy todir=${release.deploy} filtering=no
  +!-- Copy the core service xml snippet  (deploy/lib) --  
  +copy todir=${release.deploy.lib} filtering=no
  +  fileset dir=${_module.output}/etc/conf/default
  + include name=core-service.xml/
  +  /fileset
  +/copy
  +
  +!-- Copy the jetty service xml snippet  (deploy/lib) -- 
  +copy todir=${release.deploy.lib} filtering=no
  +  fileset dir=${_module.output}/etc/conf/default
  + include name=jetty-service.xml/
  +  /fileset
  +/copy
  +
  +!-- Copy the jbossmq service xml snippet  (deploy/lib) --   
  +copy todir=${release.deploy.lib} filtering=no
  +  fileset dir=${_module.output}/etc/conf/default
  + include name=jbossmq-service.xml/
  +  /fileset
  +/copy
  +
  +!-- Copy the jms service xml snippet  (deploy/lib) --   
  +copy todir=${release.deploy.lib} filtering=no
  +  fileset dir=${_module.output}/etc/conf/default
  + include name=jms-service.xml/
  +  /fileset
  +/copy
  +
  +!-- Copy the j2eedeployment service xml snippet  (deploy/lib) --
  +copy todir=${release.deploy.lib} filtering=no
  +  fileset dir=${_module.output}/etc/conf/default
  + include name=j2eedeployment-service.xml/
  +  /fileset
  +/copy
  +
  +!-- Copy the hsql defaultds service xml snippet  (deploy/lib) --
  +copy todir=${release.deploy.lib} filtering=no
 fileset dir=${_module.output}/etc/conf/default
include name=hsql-default-service.xml/
 /fileset
  @@ -600,8 +635,13 @@
   copy todir=${release.conf} filtering=no
 fileset dir=${_module.output}/etc/conf
include name=**/*/
  - exclude name=mail-service.xml/
  - exclude name=hsql-default-service.xml/
  + exclude name=default/mail-service.xml/
  + exclude name=default/core-service.xml/
  + exclude name=default/jetty-service.xml/
  + exclude name=default/jms-service.xml/
  + exclude name=default/j2eedeployment-service.xml/
  + exclude name=default/jbossmq-service.xml/
  + exclude name=default/hsql-default-service.xml/
 /fileset
   /copy
   
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] log4j switchover - anyone working on this?

[David Jencks]

The reason for the isXXXEnabled() methods is not the cost of the method
call which is minimal but to avoid constructing the log arguments which
typically involve a bunch of string manipulation which is time consuming.
The category.debug() call itself is very quick.

david jencks

On 2001.09.10 19:42:08 -0400 Hiram Chirino wrote:
 From: Jason Dillon [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] log4j switchover - anyone working on this?
 Date: Mon, 10 Sep 2001 14:41:20 -0700 (PDT)
 
 Are we still planning on dropping the older Log  Logger stuff in favor
 of
 Log4j?  If so, lets replace Logger with a new class that extends from
 Category, and provides Logger create() methods to access an instance. 
 It
 would have the trace() and isTraceEnabled().
 
 
 If going with this approach, just a isTraceEnabled public variable so
 that 
 you don't incure the cost of a method call. (since you'll be doing the
 check 
 to avoid the cost a trace method call in the first place.)
 
 Regards,
 Hiram
 
 
 _
 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
 
 

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Deployment stuff (again)

[David Maplesden]

Ok, I just committed the changes I have been working on to the deployment
mechanism.

Basically you can now use the depends tags as proposed in *service.xml
files, that is 

server
  dependsJBOSS-SYSTEM:service=Naming/depends

... your mbeans

/server

will not be deployed until the mbean with name JBOSS-SYSTEM:service=Naming
has been deployed.

Note that I have implemented this so that these tags are looked at before
the archives path, so that if you list an mbean in a depends tag that you
are expecting to have deployed by the recursive deployment mechanism then
you will be waiting for a very long time (like forever) for this to happen.

I have also changed the AutoDeployer service so that it can be started
before the utility deployers it uses, when they are started it receives a
notification and will add them to its list of available deployers.  This
means that the only service you have to start from the boot
jboss-service.xml file is the AutoDeployer, all others can be deployed by
the autodeployer.

I have changed the default configuration to make use of these changes.  I'm
pretty sure everything works, at least it all works for me.

I think the way is open now for many of the *-service.xml snippets to be
changed into sar's by people who are fully knowledgable about the various
services, instead of having everything in lib/ext.

There are still things to be looked at, like I think perhaps sar's should
contain jar's and not classes hierarchies directly and we need a mechanism
for including a default directory structure in a sar that gets expanded by
JBoss and can be used by the service (I know this has been talked about
already).

Cheers
David.

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] How to build now?

[Bill Burke]

I gotten lastest in 
awhile. How do I build now? I want to build the cluster module on 
Win2k. Do I get jboss-most? jboss-all? or what?

Thanks,

Bill

[JBoss-dev] CVS update: jbossmq/src/etc/conf/default jbossmq-service.xml

[David Maplesden]

  User: dmaplesden
  Date: 01/09/10 20:05:26

  Modified:src/etc/conf/default jbossmq-service.xml
  Log:
  Altered configuration to work with new deployment mechanism
  
  Revision  ChangesPath
  1.3   +4 -59 jbossmq/src/etc/conf/default/jbossmq-service.xml
  
  Index: jbossmq-service.xml
  ===
  RCS file: /cvsroot/jboss/jbossmq/src/etc/conf/default/jbossmq-service.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- jbossmq-service.xml   2001/09/09 05:40:47 1.2
  +++ jbossmq-service.xml   2001/09/11 03:05:26 1.3
  @@ -7,7 +7,7 @@
   !--   --
   !-- = --
   
  -!-- $Id: jbossmq-service.xml,v 1.2 2001/09/09 05:40:47 d_jencks Exp $ --
  +!-- $Id: jbossmq-service.xml,v 1.3 2001/09/11 03:05:26 dmaplesden Exp $ --
   
   !-- 
  |  This is where you can add and configure your MBeans.
  @@ -23,11 +23,11 @@
   
   server
   
  +  dependsJBOSS-SYSTEM:service=Naming/depends
   
  -
 classpath archives=
  -jbossmq.jar,
  -jbosscx.sar/
  +jbossmq.jar
  +  /
   
 !--  --
 !-- JBossMQ  --
  @@ -116,60 +116,5 @@
 name=JBossMQ:service=Queue,name=ex/
 mbean code=org.jboss.mq.server.QueueManager
 name=JBossMQ:service=Queue,name=DLQ/
  -
  -  !-- The JMS provider loader --
  -  mbean code=org.jboss.jms.jndi.JMSProviderLoader
  -  name=:service=JMSProviderLoader,name=JBossMQProvider
  -attribute name=ProviderNameDefaultJMSProvider/attribute
  -attribute name=ProviderAdapterClass
  -  org.jboss.jms.jndi.JBossMQProvider
  -/attribute
  -attribute name=QueueFactoryRefjava:/XAConnectionFactory/attribute
  -attribute name=TopicFactoryRefjava:/XAConnectionFactory/attribute
  -  /mbean
  -
  -  !-- The server session pool for Message Driven Beans --
  -  mbean code=org.jboss.jms.asf.ServerSessionPoolLoader
  -  name=:service=ServerSessionPoolMBean,name=StdJMSPool
  -attribute name=PoolNameStdJMSPool/attribute
  -attribute name=PoolFactoryClass
  -  org.jboss.jms.asf.StdServerSessionPoolFactory
  -/attribute
  -  /mbean
  -
  -  !-- JMS XA Resource adapter, use this to get transacted JMS in beans --
  -  mbean code=org.jboss.resource.ConnectionFactoryLoader
  - name=JCA:service=ConnectionFactoryLoader,name=JmsXA
  -attribute name=JndiNameJmsXA/attribute
  -attribute name=RARDeployerNameJCA:service=RARDeployer/attribute
  -attribute name=ResourceAdapterNameJMS Adapter/attribute
  -attribute name=ConnectionManagerFactoryNameMinervaXACMFactory/attribute
  -attribute name=ConnectionManagerProperties
  -  # Pool type - uncomment to force, otherwise it is the default
  -  #PoolConfiguration=per-factory
  -
  -  # Connection pooling properties - see
  -  # org.jboss.resource.connectionmanager.PoolParameters
  -  MinSize=0
  -  MaxSize=10
  -  BlockingTimeoutMillis=5000
  -  CleanupEnabled=false
  -  IdleTimeoutEnabled=false
  -  InvalidateOnError=false
  -  TrackLastUsed=false
  -  GCIntervalMillis=12
  -  GCMinIdleMillis=120
  -  IdleTimeoutMillis=180
  -  MaxIdleTimeoutPercent=1.0
  -/attribute
  -
  -attribute name=PrincipalMappingClass
  -  org.jboss.resource.security.ManyToOnePrincipalMapping
  -/attribute
  -attribute name=PrincipalMappingProperties
  -/attribute
  -  /mbean
  -
  -
   
   /server
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] How to build now?

[Jason Dillon]

jboss-all, then `build/build.bat` should build the cluster module.
jboss-most will work too, but I suggest jboss-all.

--jason


On Mon, 10 Sep 2001, Bill Burke wrote:

 I gotten lastest in awhile.  How do I build now?  I want to build the
 cluster module on Win2k.  Do I get jboss-most? jboss-all? or what?

 Thanks,

 Bill



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] How to build now?

[Bill Burke]

I get the following error on Win2k.  I had to revert to an older build.bat
to get it to compile

D:\main\jboss-all\jboss-all\buildbuild.bat
Calling ..\tools\bin\ant.bat
Buildfile: build.xml

BUILD FAILED

D:\main\jboss-all\jboss-all\build\build.xml:276: You must specify value,
locatio
n or refid with the name attribute

Total time: 4 seconds

D:\main\jboss-all\jboss-all\build


Regards,

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
 Dillon
 Sent: Monday, September 10, 2001 11:23 PM
 To: Jboss-Development@Lists. Sourceforge. Net
 Subject: Re: [JBoss-dev] How to build now?


 jboss-all, then `build/build.bat` should build the cluster module.
 jboss-most will work too, but I suggest jboss-all.

 --jason


 On Mon, 10 Sep 2001, Bill Burke wrote:

  I gotten lastest in awhile.  How do I build now?  I want to build the
  cluster module on Win2k.  Do I get jboss-most? jboss-all? or what?
 
  Thanks,
 
  Bill
 


 ___
 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] Connector module won't compile!!! Please fix this!

[Bill Burke]

Connector module is 
broken!


most-pool:[execmodules] 
== 
== Executing 'most' in module 'connector'... 
==

init-buildlog:

init:[moduleinfo] Project root: 
D:\main\jboss-most[moduleinfo] Module root: 
D:\main\jboss-most\connector

compile-classes: [javac] Modern 
compiler is not available - using classic compiler [javac] 
Compiling 1 source file to 
D:\main\jboss-most\connector\output\classes [javac] 
D:\main\jboss-most\connector\src\main\org\jboss\resource\adapter\jdbc\xa\XAManagedConnection.java:115: 
No method matching fireConnectionEvent(javax.resource.spi.ConnectionEvent) 
found in class 
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection. 
[javac] 
fireConnectionEvent(ce); 
[javac] 
^ [javac] 
D:\main\jboss-most\connector\src\main\org\jboss\resource\adapter\jdbc\xa\XAManagedConnection.java:128: 
No method matching fireConnectionEvent(javax.resource.spi.ConnectionEvent) 
found in class 
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection. 
[javac] 
fireConnectionEvent(ce); 
[javac] 
^ [javac] 2 errors

BUILD 
FAILED

D:\main\jboss-most\connector\build.xml:277: Compile 
failed, messages should havebeen provided.

Total time: 20 
seconds

D:\main\jboss-most\build

RE: [JBoss-dev] How to build now?

[David Maplesden]

I just had the same thing, its complaining about the lines...

  property name=executemodules.header![CDATA[
== 
==  Executing '${target}' in module '${module}'...
==]]/property

  property name=executemodules.footer![CDATA[
==
==  Finished with '${target}' in module '${module}'.
==
]]/property

.. if that's any help.

David

 -Original Message-
 From: Bill Burke [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, September 11, 2001 3:45 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] How to build now?
 
 
 I get the following error on Win2k.  I had to revert to an 
 older build.bat
 to get it to compile
 
 D:\main\jboss-all\jboss-all\buildbuild.bat
 Calling ..\tools\bin\ant.bat
 Buildfile: build.xml
 
 BUILD FAILED
 
 D:\main\jboss-all\jboss-all\build\build.xml:276: You must 
 specify value,
 locatio
 n or refid with the name attribute
 
 Total time: 4 seconds
 
 D:\main\jboss-all\jboss-all\build
 
 
 Regards,
 
 Bill
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On 
 Behalf Of Jason
  Dillon
  Sent: Monday, September 10, 2001 11:23 PM
  To: Jboss-Development@Lists. Sourceforge. Net
  Subject: Re: [JBoss-dev] How to build now?
 
 
  jboss-all, then `build/build.bat` should build the cluster module.
  jboss-most will work too, but I suggest jboss-all.
 
  --jason
 
 
  On Mon, 10 Sep 2001, Bill Burke wrote:
 
   I gotten lastest in awhile.  How do I build now?  I want 
 to build the
   cluster module on Win2k.  Do I get jboss-most? jboss-all? or what?
  
   Thanks,
  
   Bill
  
 
 
  ___
  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] Connector module won't compile!!! Please fix this!

[Jason Dillon]

I am in the process of updating some build files, please do not change
anything at the moment.

I will get the conenctor to build shortly, though I was not aware that it
stopped.

--jason



On Mon, 10 Sep 2001, Bill Burke wrote:

 Connector module is broken!


 most-pool:
 [execmodules]
 ==
 ==  Executing 'most' in module 'connector'...
 ==

 init-buildlog:

 init:
 [moduleinfo] Project root: D:\main\jboss-most
 [moduleinfo]  Module root: D:\main\jboss-most\connector

 compile-classes:
 [javac] Modern compiler is not available - using classic compiler
 [javac] Compiling 1 source file to
 D:\main\jboss-most\connector\output\class
 es
 [javac]
 D:\main\jboss-most\connector\src\main\org\jboss\resource\adapter\jdb
 c\xa\XAManagedConnection.java:115: No method matching
 fireConnectionEvent(javax.
 resource.spi.ConnectionEvent) found in class
 org.jboss.resource.adapter.jdbc.xa.
 XAManagedConnection.
 [javac]   fireConnectionEvent(ce);
 [javac]  ^
 [javac]
 D:\main\jboss-most\connector\src\main\org\jboss\resource\adapter\jdb
 c\xa\XAManagedConnection.java:128: No method matching
 fireConnectionEvent(javax.
 resource.spi.ConnectionEvent) found in class
 org.jboss.resource.adapter.jdbc.xa.
 XAManagedConnection.
 [javac]   fireConnectionEvent(ce);
 [javac]  ^
 [javac] 2 errors

 BUILD FAILED

 D:\main\jboss-most\connector\build.xml:277: Compile failed, messages should
 have
  been provided.

 Total time: 20 seconds

 D:\main\jboss-most\build





___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] How to build now?

[Jason Dillon]

Never seen this before either... give me a few minutes to finish up what I
am doing now and I will look into all of these problems.

--jason


On Mon, 10 Sep 2001, Bill Burke wrote:

 I get the following error on Win2k.  I had to revert to an older build.bat
 to get it to compile

 D:\main\jboss-all\jboss-all\buildbuild.bat
 Calling ..\tools\bin\ant.bat
 Buildfile: build.xml

 BUILD FAILED

 D:\main\jboss-all\jboss-all\build\build.xml:276: You must specify value,
 locatio
 n or refid with the name attribute

 Total time: 4 seconds

 D:\main\jboss-all\jboss-all\build


 Regards,

 Bill

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
  Dillon
  Sent: Monday, September 10, 2001 11:23 PM
  To: Jboss-Development@Lists. Sourceforge. Net
  Subject: Re: [JBoss-dev] How to build now?
 
 
  jboss-all, then `build/build.bat` should build the cluster module.
  jboss-most will work too, but I suggest jboss-all.
 
  --jason
 
 
  On Mon, 10 Sep 2001, Bill Burke wrote:
 
   I gotten lastest in awhile.  How do I build now?  I want to build the
   cluster module on Win2k.  Do I get jboss-most? jboss-all? or what?
  
   Thanks,
  
   Bill
  
 
 
  ___
  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] How to build now?

[Jason Dillon]

Windows?

--jason


On Tue, 11 Sep 2001, David Maplesden wrote:

 I just had the same thing, its complaining about the lines...

   property name=executemodules.header![CDATA[
 ==
 ==  Executing '${target}' in module '${module}'...
 ==]]/property

   property name=executemodules.footer![CDATA[
 ==
 ==  Finished with '${target}' in module '${module}'.
 ==
 ]]/property

 .. if that's any help.

 David

  -Original Message-
  From: Bill Burke [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, September 11, 2001 3:45 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] How to build now?
 
 
  I get the following error on Win2k.  I had to revert to an
  older build.bat
  to get it to compile
 
  D:\main\jboss-all\jboss-all\buildbuild.bat
  Calling ..\tools\bin\ant.bat
  Buildfile: build.xml
 
  BUILD FAILED
 
  D:\main\jboss-all\jboss-all\build\build.xml:276: You must
  specify value,
  locatio
  n or refid with the name attribute
 
  Total time: 4 seconds
 
  D:\main\jboss-all\jboss-all\build
 
 
  Regards,
 
  Bill
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]]On
  Behalf Of Jason
   Dillon
   Sent: Monday, September 10, 2001 11:23 PM
   To: Jboss-Development@Lists. Sourceforge. Net
   Subject: Re: [JBoss-dev] How to build now?
  
  
   jboss-all, then `build/build.bat` should build the cluster module.
   jboss-most will work too, but I suggest jboss-all.
  
   --jason
  
  
   On Mon, 10 Sep 2001, Bill Burke wrote:
  
I gotten lastest in awhile.  How do I build now?  I want
  to build the
cluster module on Win2k.  Do I get jboss-most? jboss-all? or what?
   
Thanks,
   
Bill
   
  
  
   ___
   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: [JBoss-dev] How to build now?

[David Maplesden]

Yes, I fixed it easily enough by changing them to...

  property name=executemodules.header value=Executing '${target}' in
module '${module}'.../
  property name=executemodules.footer value=...Finished with '${target}'
in module '${module}'./

I hate to add to your problems but I did a build clean followed by a build
and I get heaps of errors in the plugins/jetty module.  Interestingly this
is after the connector module which built fine for me.  I am trying to work
out what is wrong, seems to be something to do with the classpath wouldn't
you say?

I think all these problems cropped up when you changed the ant stuff in CVS
to ant 1.4 if thats any help.

(snippets from build.log)

[execmodules]Executing 'most' in module 'plugins/jetty'...

init-buildlog:

init:
[moduleinfo]Project root: W:\jboss\jboss-all
[moduleinfo] Module root: W:\jboss\jboss-all\plugins\jetty

compile-classes:
 [javac]Compiling 8 source files to
W:\jboss\jboss-all\plugins\jetty\output\classes
W:\jboss\jboss-all\plugins\jetty\src\main\org\jboss\jetty\JBossLogSink.java:
13: cannot resolve symbol
symbol  : class Code  
location: package util
import org.mortbay.util.Code;
^
W:\jboss\jboss-all\plugins\jetty\src\main\org\jboss\jetty\JBossLogSink.java:
14: cannot resolve symbol
symbol  : class Frame  
location: package util
import org.mortbay.util.Frame;
^
snip
snip
snip

W:\jboss\jboss-all\plugins\jetty\src\main\org\jboss\jetty\SetupHandler.java:
59: cannot resolve symbol
symbol  : variable super  
location: class org.jboss.jetty.SetupHandler
  super.start();
  ^
73 errors

BUILD FAILED

W:\jboss\jboss-all\plugins\jetty\build.xml:257: Compile failed, messages
should have been provided.




Cheers
David

 -Original Message-
 From: Jason Dillon [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, September 11, 2001 4:10 PM
 To: '[EMAIL PROTECTED]'
 Subject: RE: [JBoss-dev] How to build now?
 
 
 Windows?
 
 --jason
 
 
 On Tue, 11 Sep 2001, David Maplesden wrote:
 
  I just had the same thing, its complaining about the lines...
 
property name=executemodules.header![CDATA[
  
 ==
  ==  Executing '${target}' in module '${module}'...
  ==]]/property
 
property name=executemodules.footer![CDATA[
  ==
  ==  Finished with '${target}' in module '${module}'.
  
 ==
  ]]/property
 
  .. if that's any help.
 
  David
 
   -Original Message-
   From: Bill Burke [mailto:[EMAIL PROTECTED]]
   Sent: Tuesday, September 11, 2001 3:45 PM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] How to build now?
  
  
   I get the following error on Win2k.  I had to revert to an
   older build.bat
   to get it to compile
  
   D:\main\jboss-all\jboss-all\buildbuild.bat
   Calling ..\tools\bin\ant.bat
   Buildfile: build.xml
  
   BUILD FAILED
  
   D:\main\jboss-all\jboss-all\build\build.xml:276: You must
   specify value,
   locatio
   n or refid with the name attribute
  
   Total time: 4 seconds
  
   D:\main\jboss-all\jboss-all\build
  
  
   Regards,
  
   Bill
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
   Behalf Of Jason
Dillon
Sent: Monday, September 10, 2001 11:23 PM
To: Jboss-Development@Lists. Sourceforge. Net
Subject: Re: [JBoss-dev] How to build now?
   
   
jboss-all, then `build/build.bat` should build the 
 cluster module.
jboss-most will work too, but I suggest jboss-all.
   
--jason
   
   
On Mon, 10 Sep 2001, Bill Burke wrote:
   
 I gotten lastest in awhile.  How do I build now?  I want
   to build the
 cluster module on Win2k.  Do I get jboss-most? 
 jboss-all? or what?

 Thanks,

 Bill

   
   
___
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
 

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] plugins/jetty build error

[Jason Dillon]

Julian, did you forget to update the thirdparty/mortbay/jetty libs?

--jason


compile-classes:
[mkdir] Created dir:
/nfs/home/jason/ws/jboss/jboss-all/plugins/jetty/output/classes
[javac] Compiling 8 source files to
/nfs/home/jason/ws/jboss/jboss-all/plugins/jetty/output/classes
/nfs/home/jason/ws/jboss/jboss-all/plugins/jetty/src/main/org/jboss/jetty/JBossLogSink.java:13:
cannot resolve symbol
symbol  : class Code
location: package util
import org.mortbay.util.Code;
^
/nfs/home/jason/ws/jboss/jboss-all/plugins/jetty/src/main/org/jboss/jetty/JBossLogSink.java:14:
cannot resolve symbol
symbol  : class Frame
location: package util
import org.mortbay.util.Frame;
^
/nfs/home/jason/ws/jboss/jboss-all/plugins/jetty/src/main/org/jboss/jetty/JBossLogSink.java:15:
cannot resolve symbol
symbol  : class Log
location: package util
import org.mortbay.util.Log;




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] How to build now?

[Jason Dillon]

 Yes, I fixed it easily enough by changing them to...

   property name=executemodules.header value=Executing '${target}' in
 module '${module}'.../
   property name=executemodules.footer value=...Finished with '${target}'
 in module '${module}'./

This is very strange, perhaps the stuff I am about the commit will fix this.

 I hate to add to your problems but I did a build clean followed by a build
 and I get heaps of errors in the plugins/jetty module.  Interestingly this
 is after the connector module which built fine for me.  I am trying to work
 out what is wrong, seems to be something to do with the classpath wouldn't
 you say?

I can't find the classes it is looking for in thirdparty/mortbay/jetty*  I
*think* that the recent jetty commits did not include the proper support
jars.

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [JBoss-user] OpenSource and J2EE licensing (fwd)

[Jason Dillon]

I don't know if you have see this yet... I just read the notice on
enhydra.org.  I am really surprised by this.

What the *uck is Sun doing?  I generally never really read source licenses,
because they are written by lawyers.

I just want to write software...

--jason


-- Forwarded message --
Date: Mon, 10 Sep 2001 16:02:53 -0700 (PDT)
From: nathan frund [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-user] OpenSource and J2EE licensing

Hi all, recenlty Lutris pulled the plug on its
OpenSource Enhydra Enterprise server citing that J2EE
licensing is incompatible with all OpenSource
licenses. Does this have any impact on JBoss?

__
Do You Yahoo!?
Get email alerts  NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-460582 ] prefix MLET ARG VALUE with file://

[noreply]

Bugs item #460582, was opened at 2001-09-10 21:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=460582group_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: prefix MLET ARG VALUE with file://

Initial Comment:
To get Tomcat running on Windows NT the instructions 
for modifying jboss.conf were insufficient.
I got it working by prefixing TOMCAT_HOME/lib/ with
file://
e.g.
VALUE=file://c:/jakarta-tomcat-3.2.3/lib

Some more info on ClassPathExtension would be really 
useful too.

--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detailatid=376685aid=460582group_id=22866

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: thirdparty/mortbay/jetty/lib .cvsignore

[Jason Dillon]

  User: user57  
  Date: 01/09/10 21:45:12

  Removed: mortbay/jetty/lib .cvsignore
  Log:
   o oops, cvs did not ignore this

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: thirdparty/mortbay/jetty3extra - Imported sources

[Jason Dillon]

  User: user57  
  Date: 01/09/10 21:47:35

  Log:
   o Import of Jetty3Extra 0.0.7
  
  Status:
  
  Vendor Tag:   mortbay
  Release Tags: jetty3extra_0_0_7
  
  N thirdparty/mortbay/jetty3extra/lib/org.mortbay.ftp.jar
  N thirdparty/mortbay/jetty3extra/lib/jmxri.jar
  N thirdparty/mortbay/jetty3extra/lib/jmxtools.jar
  N thirdparty/mortbay/jetty3extra/lib/org.mortbay.jetty.jmx.jar
  N thirdparty/mortbay/jetty3extra/lib/org.mortbay.jetty.nbio.jar
  U thirdparty/mortbay/jetty3extra/lib/cryptix-sasl-jetty.jar
  U thirdparty/mortbay/jetty3extra/lib/javax-sasl.jar
  N thirdparty/mortbay/jetty3extra/lib/org.mortbay.jetty.sasl.jar
  N thirdparty/mortbay/jetty3extra/lib/org.mortbay.tools.jar
  
  No conflicts created by this import

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: thirdparty/mortbay/jetty - Imported sources

[Jason Dillon]

  User: user57  
  Date: 01/09/10 21:44:41

  Log:
   o import of Jetty 3.1 RC9
  
  Status:
  
  Vendor Tag:   mortbay
  Release Tags: jetty_3_1_RC9
  
  N thirdparty/mortbay/jetty/lib/.cvsignore
  N thirdparty/mortbay/jetty/lib/com.sun.net.ssl.jar
  N thirdparty/mortbay/jetty/lib/javax.xml.jaxp.jar
  N thirdparty/mortbay/jetty/lib/org.apache.crimson.jar
  N thirdparty/mortbay/jetty/lib/org.mortbay.jetty.jar
  
  No conflicts created by this import

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: thirdparty/mortbay/jetty3extra/lib com.mortbay.ftp.jar com.mortbay.jetty.jmx.jar com.mortbay.jetty.sasl.jar com.mortbay.tools.jar jmxri.jar jmxtools.jar

[Jason Dillon]

  User: user57  
  Date: 01/09/10 21:50:08

  Removed: mortbay/jetty3extra/lib com.mortbay.ftp.jar
com.mortbay.jetty.jmx.jar
com.mortbay.jetty.sasl.jar com.mortbay.tools.jar
jmxri.jar jmxtools.jar
  Log:
   o removing updated files

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development