[EJB 3.0] New message: "MDB Pool size configuration"
by Brad Warren
User development,
A new message was posted in the thread "MDB Pool size configuration":
http://community.jboss.org/message/530861#530861
Author : Brad Warren
Profile : http://community.jboss.org/people/bwarren
Message:
--------------------------------------------------------------
I'm looking for a definitive answer on configuring the pool size for an MDB. I've seen several conflicting answers between forum posts and documentation, see http://community.jboss.org/thread/147300?tstart=30
Is it the @Pool annotation? http://www.jboss.org/file-access/default/members/jbossejb3/freezone/docs/...
{code}(a)Pool(value=PoolDefaults.POOL_IMPLEMENTATION_STRICTMAX,maxSize=50,timeout=1800000){code}
Is it the @PoolClass annotation? http://www.jboss.org/ejb3/docs/reference/build/reference/en/html/session-...
{code}@PoolClass (value=org.jboss.ejb3.StrictMaxPool.class, maxSize=50, timeout=1800000){code}
Is it the MaxPoolSize ActivationConfigProperty?
{code}
@MessageDriven(
activationConfig={
...
@ActivationConfigProperty(propertyName="MaxPoolSize",propertyValue="50")
}
)
{code}
I've also seen a suggestion to change this section in ejb3-interceptors-aop.xml
{code:xml}
<annotation expr="!class((a)org.jboss.ejb3.annotation.Pool)">
@org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=15, timeout=10000)
</annotation>
{code}
But that applies to every MDB.
I've also looked at the message-driven-bean invoker-proxy-binding in standardjboss.xml and changing the MaximumSize, but that also applies to every MDB.
I've tried the @Pool annotation. I see that MaxPoolSize is 50 in the jmx-console, but if I do a thread dump when there are many thousands of messages backed up in the queue, I only see 15 WorkManager threads processing messages.
So what do I need to do to get more than 15 messages processed at once?
I'm using JBoss 5.0.1.GA and JBoss Messaging 1.4
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530861#530861
16 years, 1 month
[JBoss Web Services] New message: "Client Cert Authentication in 5.1.0"
by dfisher
User development,
A new message was posted in the thread "Client Cert Authentication in 5.1.0":
http://community.jboss.org/message/530855#530855
Author : dfisher
Profile : http://community.jboss.org/people/dfisher
Message:
--------------------------------------------------------------
I'm upgrading from version 4.2.3 to 5.1.0 and I'm having trouble getting SSL client authentication and JAAS to work correctly.
My session beans are annotated as:
@Stateless@SecurityDomain("ClientCertDomain")@WebContext( transportGuarantee = "CONFIDENTIAL", authMethod = "CLIENT-CERT")
My login-config.xml contains the following entry:
<application-policy name="ClientCertDomain"> <authentication>
<login-module code="org.jboss.security.auth.spi.DatabaseCertLoginModule" flag="sufficient"> <module-option name="securityDomain">ClientCertDomain</module-option>
..... </login-module>
</authentication> </application-policy>
Invocations of the web service fail with: faultString: (401)Unauthorized
The logs indicate that the security domain specified in the stateless session bean is "".
Application Policy not obtained for domain=. Trying to obtain the App policy for the default domain of the layer:WEB
This is apparently related to this bug: https://jira.jboss.org/jira/browse/JBAS-7037However, I cannot get the workaround to work.
Is the best course of action to attempt to update the jars in the JBoss 5.1.0 distribution?
Or is there another/better way to configure client cert based authorization?
(We can't use WS-Security yet, our clients don't support it.)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530855#530855
16 years, 1 month
[JBoss Microcontainer Development] New message: "Re: JBREFLECT-5 - Implementing generics in JavassistClassInfo"
by Kabir Khan
User development,
A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo":
http://community.jboss.org/message/530850#530850
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
> mailto:kabir.khan@jboss.com wrote:
>
>
> 3) When accessing generics from the return type of a method, e.g.
>
> Collection<String> getStringCollection(){}
>
>
>
> we get hold of this method using normal reflection (A) and construct the TypeInfo for that using the ParameterizedType (B1+2) for which I extended the Javassist TypeInfo factory:
>
> *private* *void* assertComponentType(String methodName, Class<?> expected) *throws* Exception
> {
> Method method = ClassInfoGenericClassTest.class.getMethod(methodName, (Class[]) *null*); //A
> Type type = method.getGenericReturnType(); //B1
> assertComponentType(type, expected);
> }
>
> *private* *void* assertComponentType(Type type, Class<?> expected) *throws* Exception
> {
> TypeInfoFactory factory = getTypeInfoFactory();
> TypeInfo typeInfo = factory.getTypeInfo(type); //B2
> ClassInfo classInfo = assertInstanceOf(typeInfo, ClassInfo.class);
> assertTrue(classInfo.isCollection());
>
> TypeInfo expectedInfo = factory.getTypeInfo(expected);
> assertEquals(expectedInfo, classInfo.getComponentType());
> }
>
>
> However, that is probably not what will happen in real life, we would have a ClassInfo, get hold of the MethodInfo in question, and then get the return type which should contain the actualTypeArguments. This needs implementing and is not being tested at the moment, and the same goes for parameters and field types.
Looking properly, I think what is there at the moment is correct. In reflect we have these additional methods:
Type[] Method.getGenericExceptionTypes()
Type[] Constructor.getGenericExceptionTypes()
Type[] Method.getGenericParameterTypes()
Type[] Constructor.getGenericParameterTypes()
Type Method.getGenericReturnType()
Type Field.getGenericType()
The normal non-generic methods (as getReturnType()) simply return a Class. So, I think that MethodInfo.getReturnType() should just return a plain TypeInfo as it does at the moment.
I'll concentrate on 1,2 and 4 for now, and see if 3 is needed, although I don't think so since it is not present in the reflect implementation either.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530850#530850
16 years, 1 month