jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of Mail Services] - Re: More jASEN

[mikezzz <nu...@jb...>]

Make sure you are using the JBoss Logger and not the log4j one.  Other than that the default log4j.xml configuration should just work.

Mike.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880252#3880252

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880252

[Jboss-dev-forums] [Design of JBoss Profiler] - Re: Out of memory while processing file in jboss-prifler

[mxc <nu...@jb...>]

btw - the out of memory error is when we are processing the captured log files witht the jboss-profiler.war.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880251#3880251

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880251

[Jboss-dev-forums] [Design of JBoss Profiler] - Re: Out of memory while processing file in jboss-prifler

[mxc <nu...@jb...>]

thanks for the reply. By disabling memory events will we still be able to detect memory leaks?

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880250#3880250

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880250

[Jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Integrating with JBOSS 4.0.2 and Apache 2.0.52 cause 404 err

[caigao <nu...@jb...>]

hi, all.

My env is:

Redhat AS 4.0 with apache 2.0.52
jboss 4.0.2
jdk1.5.0
mod-jk 1.2.10

mod-jk.conf set to DEBUG log using this:
  JkLogLevel debug

The war or ear application in jboss works well for example:
http://server/jmx-console

but when i put a simple a.jsp file in the apache DocumentRoot it does not work and return this message:

HTTP Status 404 - /a.jsp
--------------------------------------------------------------------------------
type Status report
message /a.jsp
description The requested resource (/a.jsp) is not available.
--------------------------------------------------------------------------------
Apache Tomcat/5.5.9


somebody can tell me what is wrong?

thank you.

there are my config files:

mod-jk.conf:

  | # Load mod_jk module
  | # Specify the filename of the mod_jk lib
  | LoadModule jk_module modules/mod_jk.so
  |  
  | # Where to find workers.properties
  | JkWorkersFile conf.d/workers.properties
  |  
  | # Where to put jk logs
  | JkLogFile logs/mod_jk.log
  |  
  | # Set the jk log level [debug/error/info]
  | # JkLogLevel info
  | JkLogLevel debug
  | 
  | # Select the log format
  | JkLogStampFormat  "[%a %b %d %H:%M:%S %Y]"
  |  
  | # JkOptions indicates to send SSK KEY SIZE
  | JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
  |  
  | # JkRequestLogFormat
  | JkRequestLogFormat "%w %V %T"
  | 
  | # Add shared memory
  | # This directive is present with 1.2.10 and
  | # later versions of mod_jk, and is needed for
  | # for load balancing to work properly
  | JkShmFile /tmp/jk.shm
  | 
  | # Add jkstatus for managing runtime data
  | <Location /jkstatus/>
  | 	JkMount jkstatus
  | 	Order deny,allow
  | 	Deny from all
  | 	Allow from 127.0.0.1
  | </Location>
  | 
  | JkMount /*.jsp 		loadbalancer
  | JkMount /*.jspx 	loadbalancer
  | JkMount /gas* 		loadbalancer
  | JkMount /wap* 		loadbalancer
  | 
  | 


workers.properties:

  | # Define list of workers that will be used
  | # for mapping requests
  | worker.list=loadbalancer,status
  | # Define Node1
  | worker.node1.port=8009
  | worker.node1.host=localhost
  | worker.node1.type=ajp13
  | worker.node1.lbfactor=1
  | #worker.node1.local_worker=1 (1)
  | worker.node1.cachesize=10
  | 
  | # Define Node2
  | #worker.node2.port=8009
  | #worker.node2.host=localhost
  | #worker.node2.type=ajp13
  | #worker.node2.lbfactor=1
  | #worker.node2.local_worker=1 (1)
  | #worker.node2.cachesize=10
  | 
  | # Load-balancing behaviour
  | worker.loadbalancer.type=lb
  | worker.loadbalancer.balanced_workers=node1
  | worker.loadbalancer.sticky_session=1
  | worker.loadbalancer.local_worker_only=1
  | worker.list=loadbalancer
  | 
  | # Status worker for managing load balancer
  | worker.status.type=status
  | 
  | #(1) local_worker should be commented out to enable load-balancing. Otherwise, only fail-over is available. 
  | 
  | 



mod-jk.log:

  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] do_shm_open::jk_shm.c (240): Truncated shared memory to 66560
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] do_shm_open::jk_shm.c (272): Initialized shared memory size=66560 free=65536 addr=0xb7fde000
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] do_shm_open_lock::jk_shm.c (182): Opened shared memory lock /tmp/jk.shm.lock
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] init_jk::mod_jk.c (2341): Initialized shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_open::jk_uri_worker_map.c (324): rule map size is 9
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (269): exact rule /jkstatus/=jkstatus was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /*.jsp=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /*.jspx=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /gas*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /wap*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /cm*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /test*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /portal*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /yck*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] uri_worker_map_open::jk_uri_worker_map.c (341): there are 9 rules
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] build_worker_map::jk_worker.c (219): creating worker loadbalancer
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] wc_create_worker::jk_worker.c (125): about to create instance loadbalancer of lb
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] wc_create_worker::jk_worker.c (138): about to validate and init loadbalancer
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] wc_create_worker::jk_worker.c (125): about to create instance node1 of ajp13
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] wc_create_worker::jk_worker.c (138): about to validate and init node1
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_validate::jk_ajp_common.c (1781): worker node1 contact is 'localhost:8009'
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1870): setting socket keepalive to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1909): setting socket timeout to -1
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1913): setting socket buffer size to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1917): setting connection recycle timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1921): setting cache timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1925): setting connect timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1929): setting reply timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1933): setting prepost timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1937): setting recovery opts to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1941): setting number of retries to 3
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (1818): setting connection cache size to 10
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] validate::jk_lb_worker.c (790): Balanced worker 0 has name node1 in domain 
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] build_worker_map::jk_worker.c (231): removing old loadbalancer worker
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] build_worker_map::jk_worker.c (219): creating worker status*loadbalancer
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] wc_create_worker::jk_worker.c (125): about to create instance status*loadbalancer of ajp13
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] wc_create_worker::jk_worker.c (138): about to validate and init status*loadbalancer
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_validate::jk_ajp_common.c (1781): worker status*loadbalancer contact is 'localhost:8009'
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1870): setting socket keepalive to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1909): setting socket timeout to -1
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1913): setting socket buffer size to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1917): setting connection recycle timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1921): setting cache timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1925): setting connect timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1929): setting reply timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1933): setting prepost timeout to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1937): setting recovery opts to 0
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_init::jk_ajp_common.c (1941): setting number of retries to 3
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (1818): setting connection cache size to 1
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] build_worker_map::jk_worker.c (231): removing old status*loadbalancer worker
  | [Sat Jun 04 05:58:28 2005][13256:63168] [debug] jk_cleanup_shmem::mod_jk.c (1735): Shmem cleanup
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] do_shm_open::jk_shm.c (240): Truncated shared memory to 66560
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] do_shm_open::jk_shm.c (272): Initialized shared memory size=66560 free=65536 addr=0xb7fde000
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] do_shm_open_lock::jk_shm.c (182): Opened shared memory lock /tmp/jk.shm.lock
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] init_jk::mod_jk.c (2341): Initialized shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_open::jk_uri_worker_map.c (324): rule map size is 9
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (269): exact rule /jkstatus/=jkstatus was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /*.jsp=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /*.jspx=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /gas*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /wap*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /cm*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /test*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /portal*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_add::jk_uri_worker_map.c (261): wildchar rule /yck*=loadbalancer was added
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] uri_worker_map_open::jk_uri_worker_map.c (341): there are 9 rules
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] build_worker_map::jk_worker.c (219): creating worker loadbalancer
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] wc_create_worker::jk_worker.c (125): about to create instance loadbalancer of lb
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] wc_create_worker::jk_worker.c (138): about to validate and init loadbalancer
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] wc_create_worker::jk_worker.c (125): about to create instance node1 of ajp13
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] wc_create_worker::jk_worker.c (138): about to validate and init node1
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_validate::jk_ajp_common.c (1781): worker node1 contact is 'localhost:8009'
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1870): setting socket keepalive to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1909): setting socket timeout to -1
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1913): setting socket buffer size to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1917): setting connection recycle timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1921): setting cache timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1925): setting connect timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1929): setting reply timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1933): setting prepost timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1937): setting recovery opts to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1941): setting number of retries to 3
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (1818): setting connection cache size to 10
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] validate::jk_lb_worker.c (790): Balanced worker 0 has name node1 in domain 
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] build_worker_map::jk_worker.c (231): removing old loadbalancer worker
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] build_worker_map::jk_worker.c (219): creating worker status*loadbalancer
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] wc_create_worker::jk_worker.c (125): about to create instance status*loadbalancer of ajp13
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] wc_create_worker::jk_worker.c (138): about to validate and init status*loadbalancer
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_validate::jk_ajp_common.c (1781): worker status*loadbalancer contact is 'localhost:8009'
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1870): setting socket keepalive to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1909): setting socket timeout to -1
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1913): setting socket buffer size to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1917): setting connection recycle timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1921): setting cache timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1925): setting connect timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1929): setting reply timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1933): setting prepost timeout to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1937): setting recovery opts to 0
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_init::jk_ajp_common.c (1941): setting number of retries to 3
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (1818): setting connection cache size to 1
  | [Sat Jun 04 05:58:28 2005][13257:63168] [debug] build_worker_map::jk_worker.c (231): removing old status*loadbalancer worker
  | [Sat Jun 04 05:58:28 2005][13260:63168] [debug] do_shm_open::jk_shm.c (200): Shared memory is already open
  | [Sat Jun 04 05:58:28 2005][13260:63168] [debug] jk_child_init::mod_jk.c (2307): Attached shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13260:63168] [debug] jk_child_init::mod_jk.c (2317): Initialized mod_jk/1.2.10
  | [Sat Jun 04 05:58:28 2005][13261:63168] [debug] do_shm_open::jk_shm.c (200): Shared memory is already open
  | [Sat Jun 04 05:58:28 2005][13261:63168] [debug] jk_child_init::mod_jk.c (2307): Attached shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13261:63168] [debug] jk_child_init::mod_jk.c (2317): Initialized mod_jk/1.2.10
  | [Sat Jun 04 05:58:28 2005][13262:63168] [debug] do_shm_open::jk_shm.c (200): Shared memory is already open
  | [Sat Jun 04 05:58:28 2005][13262:63168] [debug] jk_child_init::mod_jk.c (2307): Attached shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13262:63168] [debug] jk_child_init::mod_jk.c (2317): Initialized mod_jk/1.2.10
  | [Sat Jun 04 05:58:28 2005][13263:63168] [debug] do_shm_open::jk_shm.c (200): Shared memory is already open
  | [Sat Jun 04 05:58:28 2005][13263:63168] [debug] jk_child_init::mod_jk.c (2307): Attached shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13263:63168] [debug] jk_child_init::mod_jk.c (2317): Initialized mod_jk/1.2.10
  | [Sat Jun 04 05:58:28 2005][13264:63168] [debug] do_shm_open::jk_shm.c (200): Shared memory is already open
  | [Sat Jun 04 05:58:28 2005][13264:63168] [debug] jk_child_init::mod_jk.c (2307): Attached shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13264:63168] [debug] jk_child_init::mod_jk.c (2317): Initialized mod_jk/1.2.10
  | [Sat Jun 04 05:58:28 2005][13265:63168] [debug] do_shm_open::jk_shm.c (200): Shared memory is already open
  | [Sat Jun 04 05:58:28 2005][13265:63168] [debug] jk_child_init::mod_jk.c (2307): Attached shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13265:63168] [debug] jk_child_init::mod_jk.c (2317): Initialized mod_jk/1.2.10
  | [Sat Jun 04 05:58:28 2005][13266:63168] [debug] do_shm_open::jk_shm.c (200): Shared memory is already open
  | [Sat Jun 04 05:58:28 2005][13266:63168] [debug] jk_child_init::mod_jk.c (2307): Attached shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13266:63168] [debug] jk_child_init::mod_jk.c (2317): Initialized mod_jk/1.2.10
  | [Sat Jun 04 05:58:28 2005][13267:63168] [debug] do_shm_open::jk_shm.c (200): Shared memory is already open
  | [Sat Jun 04 05:58:28 2005][13267:63168] [debug] jk_child_init::mod_jk.c (2307): Attached shm:/tmp/jk.shm
  | [Sat Jun 04 05:58:28 2005][13267:63168] [debug] jk_child_init::mod_jk.c (2317): Initialized mod_jk/1.2.10
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] map_uri_to_worker::jk_uri_worker_map.c (455): Attempting to map URI '/a.jsp' from 9 maps
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] map_uri_to_worker::jk_uri_worker_map.c (467): Attempting to map context URI '/jkstatus/'
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] map_uri_to_worker::jk_uri_worker_map.c (467): Attempting to map context URI '/portal*'
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] map_uri_to_worker::jk_uri_worker_map.c (467): Attempting to map context URI '/*.jspx'
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] map_uri_to_worker::jk_uri_worker_map.c (467): Attempting to map context URI '/*.jsp'
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] map_uri_to_worker::jk_uri_worker_map.c (481): Found a wildchar match loadbalancer -> /*.jsp
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] jk_handler::mod_jk.c (1814): Into handler jakarta-servlet worker=loadbalancer r->proxyreq=0
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] wc_get_worker_for_name::jk_worker.c (94): found a worker loadbalancer
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] init_ws_service::mod_jk.c (483): agsp=80 agsn=www.emig.cn hostn=www.emig.cn shostn=www.emig.cn cbsport=0 sport=0 claport=80
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] service::jk_lb_worker.c (536): service sticky_session=1
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_get_endpoint::jk_ajp_common.c (2132): acquired connection cache slot=0
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] service::jk_lb_worker.c (556): service worker=node1 jvm_route=node1 rc=1
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_marshal_into_msgb::jk_ajp_common.c (551): ajp marshaling done
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_service::jk_ajp_common.c (1646): processing with 3 retries
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] jk_open_socket::jk_connect.c (317): socket TCP_NODELAY set to On
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] jk_open_socket::jk_connect.c (415): trying to connect socket 22 to 127.0.0.1:8009
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] jk_open_socket::jk_connect.c (441): socket 22 connected to 127.0.0.1:8009
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_connect_to_endpoint::jk_ajp_common.c (842): connected sd = 22 to 127.0.0.1:8009
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (898): sending to ajp13 pos=4 len=207 max=8192
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_send_request::jk_ajp_common.c (1240): request body to send 0 - request body to resend 0
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1024): received from ajp13 pos=0 len=177 max=8192
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_unmarshal_response::jk_ajp_common.c (606): status = 404
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_unmarshal_response::jk_ajp_common.c (613): Number of headers is = 3
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_unmarshal_response::jk_ajp_common.c (669): Header[0] [X-Powered-By] = [Servlet 2.4; JBoss-4.0.2 (build: CVSTag=JBoss_4_0_2 date=200505022023)/Tomcat-5.5]
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_unmarshal_response::jk_ajp_common.c (669): Header[1] [Content-Type] = [text/html;charset=utf-8]
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_unmarshal_response::jk_ajp_common.c (669): Header[2] [Content-Length] = [968]
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1024): received from ajp13 pos=0 len=972 max=8192
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ws_write::mod_jk.c (380): writing 968 (968) out of 968
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1024): received from ajp13 pos=0 len=2 max=8192
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] ajp_done::jk_ajp_common.c (2046): recycling connection cache slot=0 for worker node1
  | [Sat Jun 04 05:58:43 2005][13260:63168] loadbalancer www.emig.cn 0.004352
  | 
  | [Sat Jun 04 05:58:43 2005][13260:63168] [debug] jk_handler::mod_jk.c (1959): Service finished with status=404 for worker=loadbalancer
  | 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880237#3880237

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880237

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Delegate implementation

[<ovi...@jb...>]

In that case you need recompilation anyway, because you need to effectively implement that operation on the server delegate. So, if that need arises, you might as well add the method to XServerDelegate interface.  You will end having it duplicated on XClientDelegate AND XServerDelegate, which is not worse than what we have today. 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880230#3880230

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880230

[Jboss-dev-forums] [Design of Mail Services] - Re: need help running code from HEAD

[jeff87 <nu...@jb...>]

OK, deleted the database and it created without error upon deploy; however I still get connection refused from thunderbird. Just for kicks in Thunderbird I changed the server name from 127.0.0.1 (which worked with M2) to localhost.localdomain.com. Instead of the immediate connection refused message, it just timed out. The JBoss server still didn't show any request information in the console though.

Thanks,
Jeff

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880224#3880224

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880224

[Jboss-dev-forums] [Design of JBoss Portal] - Re: JBoss Portal Webinar Next Week

[darranl <nu...@jb...>]

http://www.jboss.com/services/online_education

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880222#3880222

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880222

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Management Aspect

[<ad...@jb...>]

You would add an @MBean annotation or whatever we want to call it.

  | <bean>
  |    <annotation name="org.jboss.aspects.jmx.MBean"/>
  | </bean>
  | 
  | The the pointcut expression determines what advice gets injected.
  | 
  |   | <interceptor class="org.jboss.aspects.jmx.LegacyJMXLifecycleAdvice" scope="PER_VM"/>
  |   | <bind pointcut="execution(* @org.jboss.aspects.jmx.MBean->*(..))">
  |   |          <interceptor-ref name="org.jboss.aspects.jmx.LegacyJMXLifecycleAdvice"/>
  |   | </bind>
  |   | 
  | 
  | That way @MBean has a logical meaning that it is implemented by the aop config.
  | It could even be NOOP if there is no aop definition.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880215#3880215

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880215

[Jboss-dev-forums] [Design of JBoss Internal Benchmarking] - Re: FileBenchmarkReceiver Thread Model vs DatabaseBenchmarkR

[<tom...@jb...>]

Using the JGropus threading model should be fine.  Just didn't know if they were set to daemon or not.  

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880208#3880208

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880208

[Jboss-dev-forums] [Design of JBoss Build System] - Re: New Build - Restate requirements

[<sco...@jb...>]

The other more likely source of the overriding dependency component version info would be the  xxx/version-info.xml descriptor mentioned in the thread I referenced.

It does make sense to state some base dependent version info in the component-info.xml of the dependee, but the actual version pulled into a given project has to be a compatible union of all dependees and the current thinking is that this is coming either from the master build directly or by a label that is mapped onto a version using the xxx/xxx/version-info.xml descriptor.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880201#3880201

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880201

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Management Aspect

[<sco...@jb...>]

Do you have a psuedo syntax for an xml deployment specification of say MyPojo, with LegacyJMXLifecycleAdvice where LegacyJMXLifecycleAdvice would be the implementation we provide that behaves similar to the existing mbean services? Assume the DynamicBean interface can be gleaned from the java bean view of MyPojo. No, this is not a test.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880198#3880198

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880198

[Jboss-dev-forums] [Design of JBoss Build System] - Re: New Build - Restate requirements

[<sco...@jb...>]

See the following thread for the far from complete discussion on this. 

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=64049

I don't have a problem with the proposed syntax as a starting point, but we should have a notion of an overriding version coming in from the top level build as an example.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880196#3880196

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880196

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Delegate implementation

[timfox <nu...@jb...>]

I think I'm understanding.

So XClientDelegate contains those operations that you know are going to be handled by interceptors somewhere (they can be on the client stack or the server stack)

XServerDelegate contains those operations that you know are never handled by interceptors.

I agree this doesn't prevent movement of interceptors from client stack to server stack.

But what if you have an operation (e.g. createMessage) that's only declared in XClientDelegate since it's handled by an interceptor, but you decide (for some strange reason) you actually want to handle it on the server.

Then both XClientDelegate and XServerDelegate need to change.

Also you might have an operation that's sometimes handled by an interceptor and sometimes by the server depending on some application state. In which case it needs to be duplicated in both interfaces.

e.g.


  | public class MyInterceptor ....
  | {
  | public Object invoke(Invocation i)
  | {
  | 
  | if (thinClient)
  | {
  | //Handle the invocation here
  | return handleHere();
  | }
  | else 
  | {
  | //Handle on server
  | return i.invokeNext();
  | }
  | }
  | 
  | 
  | 


I'm not sure if I'm making sense here. I could well be missing the point. :)



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880194#3880194

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880194

[Jboss-dev-forums] [Design of Security on JBoss] - Re: Removing MDB username and password from jboss.xml

[<ad...@jb...>]

Because the EJB2.0 MDB uses the ConnectionConsumer with a ServerSessionPool
provided by the J2EE container.

1) J2EE6.7 explicitly denies access to the ConnectionConsumer from the resource adapter
and one session per connection (not a pool of sessions like the ServerSessionPool)
2) The ConnectionConsumer requires a "static" unshared connection 
not a pooled connection

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880191#3880191

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880191

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Management Aspect

[<ad...@jb...>]

So putting this together, the solution will be to have a KernelAware
interface, but actually implement what this means in the Advice, not the POJO.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880190#3880190

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880190

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Management Aspect

[<ad...@jb...>]

"sco...@jb..." wrote : 
  | What I am still missing is who is doing the MBeanServer.registerMBean() given the DynamicMBean introduction, and at what point in the lifecycle is this done?
  | 

The answer to this question is that it is domain specific (i.e. the advice will work
in different ways).

For a pure POJO MC that just wants to expose objects for management 
through an MBeanServer it is better to do this at "INSTALL".

For compatibility with the JMX MC, i.e. within JBoss itself, the registeration will
likely need done during the INSTANTIATE phase because the
JMX MC assumes JMX registration at an early stage.
I notice you recently fixed the MBeanProxy injection to allow for more lazy
initialization, but I don't think that fully resolves this problem.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880189#3880189

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880189

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Management Aspect

[<ad...@jb...>]

"sco...@jb..." wrote : The more general question I am driving at, is how do the aspects of a component interact with the component container lifecycle states. Ignoring my abuse of aop terminology, it would seem that we need the notion of introductions on the life-cycle joinpoints (that is, state transitions). The analog for the legacy jmx kernel is that I would have to deploy the component as an xmbean and have interceptors that caught the Service method invocations.
  | 

Yes, the interceptors/advice are my preferred solution to this. Though we have
discussed in the past having a KernelAware interface.
I haven't done KernelAware because I don't want to encourage people
writing POJOs that depend upon the Kernel API.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880188#3880188

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880188

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: CLIENT_ACKNOWLEDGE optimization

[<ovi...@jb...>]

http://jira.jboss.org/jira/browse/JBMESSAGING-82



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880183#3880183

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880183

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Management Aspect

[<sco...@jb...>]

The more general question I am driving at, is how do the aspects of a component interact with the component container lifecycle states. Ignoring my abuse of aop terminology, it would seem that we need the notion of introductions on the life-cycle joinpoints (that is, state transitions). The analog for the legacy jmx kernel is that I would have to deploy the component as an xmbean and have interceptors that caught the Service method invocations.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880181#3880181

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880181

[Jboss-dev-forums] [Design of Security on JBoss] - Re: Removing MDB username and password from jboss.xml

[<sco...@jb...>]

So refresh my memory on why the jms rar cannot be used. Fundamental mismatch between jca and mdb semantics or we just don't have the neccessary pooling implementation available?

Its certainly no problem to add support for obtaining connection credentials from jaas to the JMS Provider, but if we can't configure a jca provider there would seem to be a spec mismatch here.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880179#3880179

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880179

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: OnDemand + another animals

[<sco...@jb...>]

So this gets back to the notion of knowing the existence of a component configuration at some point in the server lifecycle due to a static/deterministic configuration. The usecase I want is a static configuration one. There is a dependency injection of the DynamicClassLoading plugin, ONLY if there is a supplier of this service. If the server has been configured to not include a DynamicClassLoading, then there should be no dependency and obviously there will no injection.

This is not a relationship I can specify between truly dynamic services in a meaningful way due to the "what do I do now" interaction between the DynamicClassLoading and EJBDeployer that you describe. 

There is nothing wrong with supporting such an injection sematic such that if a provider of the DynamicClassLoading plugin shows up, it will be used for subsequent deployments.

What I was looking for was more of a declarative dependency that allows one to know that at some point in time when the mc configuration has reached some known state (t=0 for a purely static configuration, could be latter if configuration is pulled from another source), there either is a DynamicClassLoading provider and a dependency is needed to ensure all ejb deployments have a DynamicClassLoader, or there is no such provider and no ejb deployment support dynamic class loading.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880178#3880178

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880178

[Jboss-dev-forums] [Design of JBoss Portal] - Re: JBoss Portal Webinar Next Week

[cuoz <nu...@jb...>]

Unfortunately, I was unable to "attend" the webinar due to a high priority interrupt.  Is there any content that I can review on my own?  I'm disappointed that I had to miss it.  Please post URL's for anything that may be out there.

Thanks in advance.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880177#3880177

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880177

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Question on use of aspects and interceptors

[<ovi...@jb...>]

This would be great. The byzantine code you mentioned as example is a prime candidate for refactoring. My only concern is that in order to use aspects we need byte code manipulation.  



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880176#3880176

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880176

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Delegate implementation

[<ovi...@jb...>]

I don't think that both client and server delegates need to implement the same interface in order to preserve our freedom to move interceptors from client to server and back.

Consider the case of a generic delegate XDelegate with three methods a(), b() and c(). Out of these, two methods (a() and b()) are handled by interceptors and one (c()) is handled by the server delegate. Currently our design has both the client delegate (the dynamic proxy) and the server delegate implement XDelegate. On the server delegate, a() and b() are noops.

Nothing in this arrangement specifies where the interceptors are - on the client or on the server -. The only important thing is that there are interceptors that handle a() and b() somewhere between the client delegate and the server delegate. They can migrate from client to the server and back, provided the fact that a() and b() must be handled by interceptors doesn't change.

What I am proposing is to have two interfaces


  | XClientDelegate
  | {
  |   a()
  |   b()
  | }
  | 
  | XServerDelegate
  | {
  |   c()
  | }
  | 

The client-side dynamic proxy will implement both XClientDelegate and XServerDelegate. The interceptors (regardless of their location, client or server) will handle a() and b(). The server delegate only implements XServerDelegate, so there's need for noops on the server. To make things even clearer, we could use the name "InterceptorOperations" instead of "XClientDelegate".
 

Of course, there is another possibility that we completely get rid of server delegates and we handle everything with interceptors, which will render the problem completely irrelevant. However, I am not convinced yet that using server delegates is a bad idea. They offer a natural way to maintain state, for example.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880174#3880174

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880174

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Management Aspect

[<sco...@jb...>]

I was looking for where the management aspect gets introduced in the referenced thread, not how state is manipulated via jmx. Today, existence of a jmx interface is manifest when the service instance is created by the SARDeployer.

What I am still missing is who is doing the MBeanServer.registerMBean() given the DynamicMBean introduction, and at what point in the lifecycle is this done?


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880167#3880167

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880167