6.0.0.M1 Tagged! (Branch_5_x removed)
by Jason T. Greene
6.0.0.M1 has been tagged, and will be released once it passes QA. There
will be another announcement once this occurs.
Also, Branch_5_x has been removed, and all hudson jobs against it have
been disabled.
We now have one community development branch, and that is trunk.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
15 years
Re: [jboss-dev] 6.0.0.M1 Tagged! (Branch_5_x removed)
by Shelly McGowan
Alessio,
The version of the jboss-interceptor-api versions were initially defined
to align with the EJB 3.1 spec and have since been changed to align with the
interceptor version. The change to component-matrix/pom.xml was done here:
http://fisheye.jboss.org/changelog/JBossAS?cs=95930
but not in server/pom.xml
Ug!
Shelly
----- Original Message -----
From: "Alessio Soldano" <asoldano(a)redhat.com>
To: "JBoss.org development list" <jboss-development(a)lists.jboss.org>
Sent: Monday, November 30, 2009 2:09:14 PM GMT -05:00 US/Canada Eastern
Subject: Re: [jboss-dev] 6.0.0.M1 Tagged! (Branch_5_x removed)
Hi there,
I was trying to install AS 6.0.0.M1 modules' artifacts to my local m2
repository and noticed that the pom.xml in server module refer a
3.1.0-SNAPSHOT version of artifact
org.jboss.interceptor:jboss-interceptor-api.
This seems to have been added a while ago, see
http://fisheye.jboss.org/changelog/JBossAS?cs=94785 . Can you check this?
Thanks
Alessio
Jason T. Greene ha scritto:
> 6.0.0.M1 has been tagged, and will be released once it passes QA. There
> will be another announcement once this occurs.
>
> Also, Branch_5_x has been removed, and all hudson jobs against it have
> been disabled.
>
> We now have one community development branch, and that is trunk.
>
> Thanks!
>
>
--
Alessio Soldano
Web Service Lead, JBoss
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
15 years
jdk reflect bug?
by Ales Justin
While running MC/Kernel tests under security, I stumbled upon this.
Doesn't this indicate a JDK bug?
As all I'm doing is Annotation::equals.
Shouldn't it make sure it runs its internal code in privileged block?
* sun.reflect.annotation.AnnotationInvocationHandler.equalsImpl
---
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessDeclaredMembers)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1662)
at java.lang.Class.checkMemberAccess(Class.java:2125)
at java.lang.Class.getDeclaredMethods(Class.java:1762)
at
sun.reflect.annotation.AnnotationInvocationHandler.getMemberMethods(AnnotationInvocationHandler.java:257)
at
sun.reflect.annotation.AnnotationInvocationHandler.equalsImpl(AnnotationInvocationHandler.java:169)
at
sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:40)
at $Proxy22.equals(Unknown Source)
at
org.jboss.reflect.plugins.AnnotationValueImpl.equals(AnnotationValueImpl.java:149)
at java.util.HashMap.put(HashMap.java:422)
at java.util.HashSet.add(HashSet.java:194)
at
org.jboss.beans.info.plugins.AbstractBeanInfoFactory.mergeAnnotations(AbstractBeanInfoFactory.java:352)
at
org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanProperties(AbstractBeanInfoFactory.java:311)
at
org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:157)
at
org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:124)
at
org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:81)
at
org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:894)
--- AnnotationValueImpl
@Override
public boolean equals(Object o)
{
if (this == o) return true;
if (o == null || !(o instanceof AnnotationValue)) return false;
final AnnotationValue annotationValue = (AnnotationValue) o;
if (!annotationType.equals(annotationValue.getAnnotationType()))
return false;
if (!attributeValues.equals(annotationValue.getValues())) return
false;
Annotation otherUnderlying =
annotationValue.getUnderlyingAnnotation();
if (underlying == null && otherUnderlying != null)
return false;
if (underlying != null && otherUnderlying == null)
return false;
return underlying.equals(otherUnderlying);
}
15 years
Fwd: JBoss-AS-6.0.x-testSuite-sun16 - Build # 419 - Still Failing!
by Brian Stansberry
The testsuite is failing in the jboss-minimal-tests. I believe this is
because the new naming-jboss-beans.xml isn't in the minimal/deploy dir.
Is anyone looking at this? If not I'll fix it.
-------- Original Message --------
Date: Fri, 20 Nov 2009 07:53:23 -0500 (EST)
From: jboss-qa-internal(a)redhat.com
To: builds(a)lists.jboss.org, bstansberry(a)redhat.com
Subject: JBoss-AS-6.0.x-testSuite-sun16 - Build # 419 - Still Failing!
JBoss-AS-6.0.x-testSuite-sun16 - Build # 419 - Still Failing:
Check console output at
https://hudson.jboss.org/hudson//job/JBoss-AS-6.0.x-testSuite-sun16/419
to view the results.
Modifications since last build:
[bstansberry(a)jboss.com] [JBAS-7473] Configure clustered session manager
in JBossContextConfig
_______________________________________________
builds mailing list
builds(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/builds
15 years, 1 month
Naming over Remoting 3
by Ron Sigal
I subject has arisen in JBAS-3151 "Convert HA-JNDI stubs to Remoting"
that Brian has suggested deserves some discussion. I've started a forum
thread
(http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266436#4266436),
but here's the teaser:
*"ron" wrote:*
...
Is there anything wrong with HARMIClient and HARMIServer, other than the
fact that they depend on RMI?
---
*"brian" wrote:*
Not particularly, no. I think the main issues are 1) we want to unify as
much as possible on a single remote invocation mechanism 2) get rid of
myriad sockets opened by different services. I suppose the latter goes
beyond the description of this JIRA as it involve converting
HANamingService to use a Remoting connector instead of directly
listening on port 1101.
*"ron" wrote:*
It looks like there are two kinds of Naming listeners:
1. the "bootstrap" listeners in org.jnp.server.Main and
org.jboss.ha.jndi.HANamingService, and
2. the actual service listeners: org.jnp.server.NamingServer and
org.jboss.ha.framework.server.HARMIServerImpl
So, we'd like to replace them all with handlers on a single Remoting
connector (or, actually, the Remoting 3 version of of handlers and
connectors).
*"brian" wrote:*
The bootstrap listener part probably bears discussion on the jboss-dev
list since it much more directly impacts stuff like end-user
configuration (i.e. jndi.properties or other ways of setting the
properties passed to new InitialContext()). The service listeners are
more straightforward.
Discuss?
-Ron
15 years, 1 month
Branch_5_x Code Freeze!
by Jason T. Greene
We are trying to get a reliable hudson run before we tag. Please don't
commit anything without posting about it here first.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
15 years, 1 month
DefaultJndiBinder use of jndi from constructor
by Scott Stark
I'm looking at moving the jndi beans into deploy, and one issue I have
run into is that the DefaultJndiBinder deployed from
deployers/beanvalidation.deployer/META-INF/bv-core-jboss-beans.xml is
attempting to access jndi from its ctor:
19:59:25,942 ERROR [DefaultJndiBinder] Unable to create JNDI subcontext
for Bean Validation Factories: javax.naming.CommunicationException:
Receive timed out [Root exception is java.net.SocketTimeoutException:
Receive timed out]
at
org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:1678)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1795)
at
org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:1106)
at
org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:1096)
at javax.naming.InitialContext.createSubcontext(InitialContext.java:464)
at
org.jboss.beanvalidation.util.DefaultJndiBinder.createSubContextForFactories(DefaultJndiBinder.java:65)
at
org.jboss.beanvalidation.util.DefaultJndiBinder.<init>(DefaultJndiBinder.java:57)
at
org.jboss.beanvalidation.util.DefaultJndiBinder.<init>(DefaultJndiBinder.java:51)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:149)
at
org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
at
org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
at
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:295)
at
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:116)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:243)
at
org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:111)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72)
at
org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:66)
I can get around this by adding a demand from the binder's Instantiated
state:
<!-- Default JNDI name creator -->
<bean name="DefaultJndiBinder"
class="org.jboss.beanvalidation.util.DefaultJndiBinder">
<demand state="Instantiated">LocalNamingBean</demand>
</bean>
but I'm wondering if this should be done from a more typical lifecycle
method to simplify dependency configuration.
15 years, 1 month
