tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: files configuration of tomee
Date Thu, 05 Sep 2013 15:57:36 GMT
Hi

Openejb.xml is relevant for openejb (standalone or embedded), tomee.xml for
tomee (openejb.xml is used when tomee.xml doesnt exist)

Service-jar.xml is no more relevant today excepted when you want to define
defaults values for a resource. You put it in META-INF/x where x is the
package you want then reference it in the resource tag through the
attribute provider. It has to be in the classpath when the resource is
created (container often often)

Of course there is a singleton container (globally singpeton or stateless
beans are the same excepted the lifecycle) and the conf is read.
Le 5 sept. 2013 16:21, "mauro2java2011" <mauro2java2011@gmail.com> a écrit :

>
> the files openejb.xml and tomee.xml are the same thing? When to use one or
> the other?
>
> where and when to use the service-jar.xml file?? where you have to meterlo?
> web.inf in a single web application? Or diatoms in / lib or tomm / class???
>
> i have noted also int othe openejb.xml the following declaration:
>
> <Container id="My Singleton Container" type="SINGLETON">
>   # Specifies the maximum time an invocation could wait for the
>   # singleton bean instance to become available before giving up.
>   #
>   # After the timeout is reached a
> javax.ejb.ConcurrentAccessTimeoutException
>   # will be thrown.
>   #
>   # Usable time units: nanoseconds, microsecons, milliseconds,
>   # seconds, minutes, hours, days. Or any combination such as
>   # "1 hour and 27 minutes and 10 seconds"
>
>   AccessTimeout = 30 seconds
>
> </Container>
>
>
> <Container id="My Stateful Container" type="STATEFUL">
>   # Specifies the maximum time an invocation could wait for the
>   # stateful bean instance to become available before giving up.
>   #
>   # After the timeout is reached a
> javax.ejb.ConcurrentAccessTimeoutException
>   # will be thrown.
>   #
>   # Usable time units: nanoseconds, microsecons, milliseconds,
>   # seconds, minutes, hours, days. Or any combination such as
>   # "1 hour and 27 minutes and 10 seconds"
>
>   AccessTimeout = 30 seconds
>
>   # The passivator is responsible for writing beans to disk
>   # at passivation time. Different passivators can be used
>   # by setting this property to the fully qualified class name
>   # of the PassivationStrategy implementation. The passivator
>   # is not responsible for invoking any callbacks or other
>   # processing, its only responsibly is to write the bean state
>   # to disk.
>   #
>   # Known implementations:
>   # org.apache.openejb.core.stateful.RAFPassivater
>   # org.apache.openejb.core.stateful.SimplePassivater
>
>   Passivator org.apache.openejb.core.stateful.SimplePassivater
>
>   # Specifies the time to wait between invocations. This
>   # value is measured in minutes. A value of 5 would
>   # result in a time-out of 5 minutes between invocations.
>   # A value of zero would mean no timeout.
>
>   TimeOut 20
>
>   # Specifies the frequency (in seconds) at which the bean cache is checked
> for
>   # idle beans.
>
>   Frequency 60
>
>   # Specifies the size of the bean pools for this
>   # stateful SessionBean container.
>
>   Capacity 1000
>
>   # Property name that specifies the number of instances
>   # to passivate at one time when doing bulk passivation.
>   # Must be less than the PoolSize.
>
>   BulkPassivate 100
>
> </Container>
>
>
> <Container id="My Stateless Container" type="STATELESS">
>
>   # Specifies the time an invokation should wait for an instance
>   # of the pool to become available.
>   #
>   # After the timeout is reached, if an instance in the pool cannot
>   # be obtained, the method invocation will fail.
>   #
>   # Usable time units: nanoseconds, microsecons, milliseconds,
>   # seconds, minutes, hours, days. Or any combination such as
>   # "1 hour and 27 minutes and 10 seconds"
>
>   AccessTimeout = 30 seconds
>
>   # Specifies the size of the bean pools for this stateless
>   # SessionBean container. If StrictPooling is not used, instances
>   # will still be created beyond this number if there is demand, but
>   # they will not be returned to the pool and instead will be
>   # immediately destroyed.
>
>   MaxSize = 10
>
>   # Specifies the minimum number of bean instances that should be in
>   # the pool for each bean. Pools are prefilled to the minimum on
>   # startup. Note this will create start order dependencies between
>   # other beans that also eagerly start, such as other @Stateless
>   # beans with a minimum or @Singleton beans using @Startup. The
>   # @DependsOn annotation can be used to appropriately influence
>   # start order.
>   #
>   # The minimum pool size is rigidly maintained. Instances in the
>   # minimum side of the pool are not eligible for IdleTimeout or
>   # GarbageCollection, but are subject to MaxAge and flushing.
>   #
>   # If the pool is flushed it is immediately refilled to the minimum
>   # size with MaxAgeOffset applied. If an instance from the minimum
>   # side of the pool reaches its MaxAge, it is also immediately
>   # replaced. Replacement is done in a background queue using the
>   # number of threads specified by CallbackThreads.
>
>   MinSize = 0
>
>   # StrictPooling tells the container what to do when the pool
>   # reaches it's maximum size and there are incoming requests that
>   # need instances.
>   #
>   # With strict pooling, requests will have to wait for instances to
>   # become available. The pool size will never grow beyond the the
>   # set MaxSize value. The maximum amount of time a request should
>   # wait is specified via the AccessTimeout setting.
>   #
>   # Without strict pooling, the container will create temporary
>   # instances to meet demand. The instances will last for just one
>   # method invocation and then are removed.
>   #
>   # Setting StrictPooling to false and MaxSize to 0 will result in
>   # no pooling. Instead instances will be created on demand and live
>   # for exactly one method call before being removed.
>
>   StrictPooling = true
>
>   # Specifies the maximum time that an instance should live before
>   # it should be retired and removed from use. This will happen
>   # gracefully. Useful for situations where bean instances are
>   # designed to hold potentially expensive resources such as memory
>   # or file handles and need to be periodically cleared out.
>   #
>   # Usable time units: nanoseconds, microsecons, milliseconds,
>   # seconds, minutes, hours, days. Or any combination such as
>   # "1 hour and 27 minutes and 10 seconds"
>
>   MaxAge = 0 hours
>
>   # Specifies the maximum time that an instance should be allowed to
>   # sit idly in the pool without use before it should be retired and
>   # removed.
>   #
>   # Usable time units: nanoseconds, microsecons, milliseconds,
>   # seconds, minutes, hours, days. Or any combination such as
>   # "1 hour and 27 minutes and 10 seconds"
>
>   IdleTimeout = 0 minutes
>
> </Container>
>
> They are statements of singleton that act as containers?
> As they are taken into account when tomee   start?
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/files-configuration-of-tomee-tp4664993.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message