Nabble - JBoss

Re: 6.0.0.M1 Tagged! (Branch_5_x removed)

2009-12-01T12:03:05Z

I think you mean JBMETA-223. The JPA metadata should be split off from
EJB metadata.

Carlo

On 11/25/2009 04:15 PM, Scott Marlow wrote:

> I committed my changes, I needed to delete my local maven repository
> before building. Next we need to fix JBMETA-233 on AS trunk.
>
> On 11/25/2009 08:11 AM, Scott Marlow wrote:
>
>> I started making local changes to bring some of the JPA-2 pieces over to
>> AS trunk. I'm currently, getting a clean build and can run the AS smoke
>> tests successfully. I'm going to merge a little more from M1 and will
>> hopefully check in soon.
>>
>> My current changes (patch form) are here http://www.pastie.org/714393
>>
>> Scott
>>
>> On 11/20/2009 05:17 PM, Jason T. Greene wrote:
>>
>>
>>> 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!
>>>
>>>
>>>
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development@...
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development
>

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Byteman 1.2.0 release now available

2009-12-01T10:10:36Z

Byteman release 1.2.0 has now been released and is available from the
project downloads page http://www.jboss.org/byteman/downloads.

This release is primarily a feature upgrade extending the Byteman rule
language to support two new types of rules:

interface rules
-- rule code is injected through an interface into all classes which
implement the interface

overriding rules
-- rule code is injected down class hierarchies into a both the target
class's method and into the methods of subclasses which provides an
overriding implementation

These two new modes of injection may be used in isolation but they also
work in combination. For example, the following rule adds trace code to
the run method of every implementor of Runnable and to every overriding
implementation, effectively tracing every run() operation in the JVM.

RULE trace any Runnable.run() call
INTERFACE ^java.lang.Runnable
METHOD run()
IF TRUE
DO System.out.println("Running runnable " + $0 +
" " + $0.getClass().getName())
ENDRULE

Full details of the syntax and operation of these two new rule types are
included in the 1.2.0 programmers guide.

The release also includes several bug fixes including, most notably, a
much more reliable implementation of tool bytemancheck, which performs
offline rule syntax and type checking. Release notes are available from
the project downloads page http://www.jboss.org/byteman/downloads.
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: 6.0.0.M1 Tagged! (Branch_5_x removed)

2009-11-30T12:59:39Z

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@...>
To: "JBoss.org development list" <jboss-development@...>
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@...
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: 6.0.0.M1 Tagged! (Branch_5_x removed)

2009-11-30T11:09:14Z

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:

From forum: JBoss - Dev

Virtual hosts deploy webapp multiple times

2009-11-26T16:04:38Z

Hi there,
it's been a long time I have some applications using virtual hosts in JBoss. I see that JBoss deploys webapps multiple times, one for each virtual host. I wonder if this is the supposed behaviour or if this can be fixed someway.

I am using latest Jboss 5.1GA version.

thanks for any help,
Ignacio

From forum: JBoss - Dev

Re: Annotation scanning in wars doesn't work anymore

2009-11-26T08:54:44Z

On Thu, Nov 26, 2009 at 5:45 PM, Emanuel Muckenhuber
<emuckenh@...> wrote:
> Hmm we also need to make sure that you can use the AnnotationEnvironment
> (or the outstanding Papaki annotation scanning thingy) instead of the
> AnnotatedClassFilter in future. AFAIK the later one was much slower. It
> also means that the classpath is scanned twice for annotations (first
> from AE and then from the AnnotatedClassFilter) which should be avoided.
>
> I guess you cannot use the AnnotationEnvironment for now since you need
> scanning the reference to the web-fragment/jar?

Yes, scanning per JAR is needed, I did put it in the requirements wiki
for future annotation work.

Right now, it's either:
1) use the slow AnnotationMetaDataDeployer everywhere
2) use WarAnnotationMetaDataDeployer for web stuff and
OptAnnotationMetaDataDeployer elsewhere
Solution 2) is used.

For Carlo: You can update OptAnnotationMetaDataDeployer as you need,
web annotations processing is not done there. Your change looks ok to
me.

Rémy

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Annotation scanning in wars doesn't work anymore

2009-11-26T08:50:03Z

At some point in AS 5.0 we did do EJBs in wars (
https://jira.jboss.org/jira/browse/JBAS-5281 ), but that lead to
problems were people would actually package EJBs in wars. :-)

In AS 5.1 it doesn't work ( https://jira.jboss.org/jira/browse/JBAS-7312
), but that's because we needed to forcibly disable it and thus it
wasn't tested anymore.

Now for AS 6 we need it again for EJB 3.1 spec. :-)

I've locally modified that to:

protected void processMetaData(VFSDeploymentUnit unit, WebMetaData webMetaData, ApplicationClientMetaData clientMetaData, List<VirtualFile> classpath) throws Exception
{
AnnotationFinder<AnnotatedElement> finder = new DefaultAnnotationFinder<AnnotatedElement>();
// don't do webMetaData anymore (rev 96033)

String mainClassName = getMainClassName(unit);
if(mainClassName != null)
processJBossClientMetaData(unit, finder, mainClassName);
else
processJBossMetaData(unit, finder);
}

But yes, these concerns need to be separated out.

Carlo

On 11/26/2009 05:41 PM, Rémy Maucherat wrote:

> On Thu, Nov 26, 2009 at 5:31 PM, Emanuel Muckenhuber
> <emuckenh@...> wrote:
>
>> The AnnotationMetaDataDeployer should be split up anyway. Seems Remy did
>> the first step.
>>
>> Was this really working before? As far as i can remember we always
>> skipped ejb3 processing when there was a WebMetaData present?
>>
> I did remove the "skip if it's a war" test, but indeed, there is a
> test like that:
> if(webMetaData != null)
> {
> processJBossWebMetaData(unit, finder);
> }
> else if (clientMetaData != null)
> {
> String mainClassName = getMainClassName(unit);
> if(mainClassName != null)
> processJBossClientMetaData(unit, finder, mainClassName);
> }
> else
> {
> String mainClassName = getMainClassName(unit);
> if (mainClassName != null)
> processJBossClientMetaData(unit, finder, mainClassName);
> else
> processJBossMetaData(unit, finder);
> }
>
> Rémy
>
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development
>

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Annotation scanning in wars doesn't work anymore

2009-11-26T08:45:00Z

On 11/26/2009 05:26 PM, Rémy Maucherat wrote:

> On Thu, Nov 26, 2009 at 5:00 PM, Carlo de Wolf<cdewolf@...> wrote:
>> Because of this change
>> http://fisheye.jboss.org/browse/JBossAS/trunk/server/src/main/java/org/jboss/deployment/AnnotationMetaDataDeployer.java?r1=93962&r2=96033
>> annotation scanning doesn't work anymore and thus EJBs (in wars) won't
>> get deployed.
>>
>> Suggestions?
>
> Oooops. At the moment annotations that are processed by
> Web30MetaDataCreator need to get special treatment in a different
> deployer, so this was a (bad) attempt to avoid doing things twice.
> Fixed.
>
> I have the impression that the other annotations will need to be
> processed per JAR eventually, but this is not urgent ...
>

Hmm we also need to make sure that you can use the AnnotationEnvironment
(or the outstanding Papaki annotation scanning thingy) instead of the
AnnotatedClassFilter in future. AFAIK the later one was much slower. It
also means that the classpath is scanned twice for annotations (first
from AE and then from the AnnotatedClassFilter) which should be avoided.

I guess you cannot use the AnnotationEnvironment for now since you need
scanning the reference to the web-fragment/jar?
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Annotation scanning in wars doesn't work anymore

2009-11-26T08:41:42Z

On Thu, Nov 26, 2009 at 5:31 PM, Emanuel Muckenhuber
<emuckenh@...> wrote:
> The AnnotationMetaDataDeployer should be split up anyway. Seems Remy did
> the first step.
>
> Was this really working before? As far as i can remember we always
> skipped ejb3 processing when there was a WebMetaData present?

I did remove the "skip if it's a war" test, but indeed, there is a
test like that:
if(webMetaData != null)
{
processJBossWebMetaData(unit, finder);
}
else if (clientMetaData != null)
{
String mainClassName = getMainClassName(unit);
if(mainClassName != null)
processJBossClientMetaData(unit, finder, mainClassName);
}
else
{
String mainClassName = getMainClassName(unit);
if (mainClassName != null)
processJBossClientMetaData(unit, finder, mainClassName);
else
processJBossMetaData(unit, finder);
}

Rémy

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Annotation scanning in wars doesn't work anymore

2009-11-26T08:31:30Z

The AnnotationMetaDataDeployer should be split up anyway. Seems Remy did
the first step.

Was this really working before? As far as i can remember we always
skipped ejb3 processing when there was a WebMetaData present?

On 11/26/2009 05:00 PM, Carlo de Wolf wrote:

> Because of this change
> http://fisheye.jboss.org/browse/JBossAS/trunk/server/src/main/java/org/jboss/deployment/AnnotationMetaDataDeployer.java?r1=93962&r2=96033
> annotation scanning doesn't work anymore and thus EJBs (in wars) won't
> get deployed.
>
> Suggestions?
>
> Carlo
>
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Annotation scanning in wars doesn't work anymore

2009-11-26T08:26:53Z

On Thu, Nov 26, 2009 at 5:00 PM, Carlo de Wolf <cdewolf@...> wrote:
> Because of this change
> http://fisheye.jboss.org/browse/JBossAS/trunk/server/src/main/java/org/jboss/deployment/AnnotationMetaDataDeployer.java?r1=93962&r2=96033
> annotation scanning doesn't work anymore and thus EJBs (in wars) won't
> get deployed.
>
> Suggestions?

Oooops. At the moment annotations that are processed by
Web30MetaDataCreator need to get special treatment in a different
deployer, so this was a (bad) attempt to avoid doing things twice.
Fixed.

I have the impression that the other annotations will need to be
processed per JAR eventually, but this is not urgent ...

Rémy

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Annotation scanning in wars doesn't work anymore

2009-11-26T08:00:11Z

Because of this change
http://fisheye.jboss.org/browse/JBossAS/trunk/server/src/main/java/org/jboss/deployment/AnnotationMetaDataDeployer.java?r1=93962&r2=96033
annotation scanning doesn't work anymore and thus EJBs (in wars) won't
get deployed.

Suggestions?

Carlo

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

org.jboss.deployers.spi.DeploymentException: Error deploying: DefaultPersistenceProperties

2009-11-26T07:29:54Z

Whenever I am running an application on JBoss Server I am getting this exception

From forum: JBoss - Dev

Re: 6.0.0.M1 Tagged! (Branch_5_x removed)

2009-11-25T07:15:01Z

I committed my changes, I needed to delete my local maven repository
before building. Next we need to fix JBMETA-233 on AS trunk.

On 11/25/2009 08:11 AM, Scott Marlow wrote:

> I started making local changes to bring some of the JPA-2 pieces over to
> AS trunk. I'm currently, getting a clean build and can run the AS smoke
> tests successfully. I'm going to merge a little more from M1 and will
> hopefully check in soon.
>
> My current changes (patch form) are here http://www.pastie.org/714393
>
> Scott
>
> On 11/20/2009 05:17 PM, Jason T. Greene wrote:
>
>> 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!
>>
>>
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development
>

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: 6.0.0.M1 Tagged! (Branch_5_x removed)

2009-11-25T05:11:01Z

I started making local changes to bring some of the JPA-2 pieces over to
AS trunk. I'm currently, getting a clean build and can run the AS smoke
tests successfully. I'm going to merge a little more from M1 and will
hopefully check in soon.

My current changes (patch form) are here http://www.pastie.org/714393

Scott

On 11/20/2009 05:17 PM, Jason T. Greene wrote:

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-24T07:25:07Z

According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6761678
, looks like it will be fixed in "7(b40), 6-open(b13)"

On 11/24/2009 10:14 AM, Anil Saldhana wrote:

> Not when the fix is simple and it is related to security.
>
> On 11/24/2009 02:09 AM, Emmanuel Bernard wrote:
>
>> It's not like it never happens to us :)
>>
>> On 23 nov. 09, at 23:18, Anil Saldhana wrote:
>>
>>
>>
>>> In 12+ months, no attempt was made to fix the bug?
>>>
>>> On 11/23/2009 03:54 PM, Ales Justin wrote:
>>>
>>>
>>>> Yeah, confirmed bug:
>>>> *
>>>> http://mail.openjdk.java.net/pipermail/security-dev/2008-October/000356.html
>>>> * http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4140596
>>>> (remembered I've seen this before :-)
>>>>
>>>> Anil Saldhana wrote:
>>>>
>>>>
>>>>
>>>>> I agree that it is a JDK bug.
>>>>>
>>>>>
>>>>>
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development
>

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-24T07:14:05Z

Not when the fix is simple and it is related to security.

On 11/24/2009 02:09 AM, Emmanuel Bernard wrote:

> It's not like it never happens to us :)
>
> On 23 nov. 09, at 23:18, Anil Saldhana wrote:
>
>
>> In 12+ months, no attempt was made to fix the bug?
>>
>> On 11/23/2009 03:54 PM, Ales Justin wrote:
>>
>>> Yeah, confirmed bug:
>>> *
>>> http://mail.openjdk.java.net/pipermail/security-dev/2008-October/000356.html
>>> * http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4140596
>>> (remembered I've seen this before :-)
>>>
>>> Anil Saldhana wrote:
>>>
>>>
>>>> I agree that it is a JDK bug.
>>>>
>>>>

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-24T00:09:03Z

It's not like it never happens to us :)

On 23 nov. 09, at 23:18, Anil Saldhana wrote:

> In 12+ months, no attempt was made to fix the bug?
>
> On 11/23/2009 03:54 PM, Ales Justin wrote:
>> Yeah, confirmed bug:
>> *
>> http://mail.openjdk.java.net/pipermail/security-dev/2008-October/000356.html
>> * http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4140596
>> (remembered I've seen this before :-)
>>
>> Anil Saldhana wrote:
>>
>>> I agree that it is a JDK bug.
>>>
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-23T14:18:12Z

In 12+ months, no attempt was made to fix the bug?

On 11/23/2009 03:54 PM, Ales Justin wrote:

> Yeah, confirmed bug:
> *
> http://mail.openjdk.java.net/pipermail/security-dev/2008-October/000356.html
> * http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4140596
> (remembered I've seen this before :-)
>
> Anil Saldhana wrote:
>
>> I agree that it is a JDK bug.
>>
>

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-23T13:54:38Z

Yeah, confirmed bug:
*
http://mail.openjdk.java.net/pipermail/security-dev/2008-October/000356.html
* http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4140596
(remembered I've seen this before :-)

Anil Saldhana wrote:
> I agree that it is a JDK bug.
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-23T12:16:21Z

I agree that it is a JDK bug. When you make a call to
annotation.equals, the JDK is internally getting the declared methods
which require permissions. A lack of privileged block in the JDK
internal implementation is exposing the permission requirement to the
JVM client code.

On 11/23/2009 02:12 PM, Ales Justin wrote:

> Yeah, that makes it go away,
> but that's not the fix, it's a workaround. :-)
>
> Anil Saldhana wrote:
>
>> Add a priv block to line 149 of the Impl class. Tell us what the
>> behavior is. I think that is what is missing.
>>
>> On 11/23/2009 01:43 PM, Anil Saldhana wrote:
>>
>>> What happens when you place
>>>
>>> org.jboss.reflect.plugins.AnnotationValueImpl.equals(AnnotationValueImpl.java:149)
>>>
>>>
>>> under a privileged block?
>>>
>>> On 11/23/2009 01:14 PM, Ales Justin wrote:
>>>
>>>
>>>> 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);
>>>> }

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-23T12:12:40Z

Yeah, that makes it go away,
but that's not the fix, it's a workaround. :-)

Anil Saldhana wrote:

> Add a priv block to line 149 of the Impl class. Tell us what the
> behavior is. I think that is what is missing.
>
> On 11/23/2009 01:43 PM, Anil Saldhana wrote:
>> What happens when you place
>>
>> org.jboss.reflect.plugins.AnnotationValueImpl.equals(AnnotationValueImpl.java:149)
>>
>>
>> under a privileged block?
>>
>> On 11/23/2009 01:14 PM, Ales Justin wrote:
>>
>>> 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);
>>> }
>
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development
>

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-23T12:04:53Z

Add a priv block to line 149 of the Impl class. Tell us what the
behavior is. I think that is what is missing.

On 11/23/2009 01:43 PM, Anil Saldhana wrote:

> What happens when you place
>
> org.jboss.reflect.plugins.AnnotationValueImpl.equals(AnnotationValueImpl.java:149)
>
>
> under a privileged block?
>
> On 11/23/2009 01:14 PM, Ales Justin wrote:
>
>> 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);
>> }

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: jdk reflect bug?

2009-11-23T11:43:54Z

What happens when you place

org.jboss.reflect.plugins.AnnotationValueImpl.equals(AnnotationValueImpl.java:149)

under a privileged block?

On 11/23/2009 01:14 PM, Ales Justin wrote:

> 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);
> }

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

jdk reflect bug?

2009-11-23T11:14:14Z

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);
}

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: 6.0.0.M1 Tagged! (Branch_5_x removed)

2009-11-23T06:18:42Z

Sure, that'll help with my Hudson instance. Locally I'll just use
-Pdist-zip.

S,
ALR

On 11/23/2009 09:11 AM, Jason T. Greene wrote:

> This hasn't been uploaded yet since it hasn't passed QA. I can push a
> 6.0.0.M1-SNAPSHOT if it helps.
>
> Andrew Lee Rubinger wrote:
>> I'm not seeing org.jboss.jbossas:jboss-as-distribution in my local repo
>> or the SNAPSHOTs repo:
>>
>> http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-distribution/
>> (I'm looking for a "6.0.0.M1" as 6.0.0-SNAPSHOT is trunk).
>>
>> This was renamed from artifactId jboss-as-build in JBBUILD-568, where I
>> asked Paul for a "distribution" assembly.
>>
>> EmbeddedAS will need to depend upon this artifact for release now that
>> jboss-as-build is gone.
>>
>> S,
>> ALR
>>
>> On 11/20/2009 05:17 PM, Jason T. Greene wrote:
>>> 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!
>>>
>>
>
>

--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: 6.0.0.M1 Tagged! (Branch_5_x removed)

2009-11-23T06:11:47Z

This hasn't been uploaded yet since it hasn't passed QA. I can push a
6.0.0.M1-SNAPSHOT if it helps.

Andrew Lee Rubinger wrote:

> I'm not seeing org.jboss.jbossas:jboss-as-distribution in my local repo
> or the SNAPSHOTs repo:
>
> http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-distribution/
> (I'm looking for a "6.0.0.M1" as 6.0.0-SNAPSHOT is trunk).
>
> This was renamed from artifactId jboss-as-build in JBBUILD-568, where I
> asked Paul for a "distribution" assembly.
>
> EmbeddedAS will need to depend upon this artifact for release now that
> jboss-as-build is gone.
>
> S,
> ALR
>
> On 11/20/2009 05:17 PM, Jason T. Greene wrote:
>> 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
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: 6.0.0.M1 Tagged! (Branch_5_x removed)

2009-11-21T18:28:54Z

I'm not seeing org.jboss.jbossas:jboss-as-distribution in my local repo
or the SNAPSHOTs repo:

http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-distribution/
(I'm looking for a "6.0.0.M1" as 6.0.0-SNAPSHOT is trunk).

This was renamed from artifactId jboss-as-build in JBBUILD-568, where I
asked Paul for a "distribution" assembly.

EmbeddedAS will need to depend upon this artifact for release now that
jboss-as-build is gone.

S,
ALR

On 11/20/2009 05:17 PM, Jason T. Greene wrote:

From forum: JBoss - Dev

6.0.0.M1 Tagged! (Branch_5_x removed)

2009-11-20T14:17:17Z

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
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Fwd: JBoss-AS-6.0.x-testSuite-sun16 - Build # 419 - Still Failing!

2009-11-20T13:07:42Z

I have resolved this issue.

Shelly McGowan wrote:

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

How do I access java mail from the InitialContext ?

2009-11-20T12:30:42Z

Hi,

I'm using JBoss 5.1 (Java 1.6) on Mac 10.5.6. I haev a web application and am trying to access the mail session via

return (Session) new InitialContext().lookup(getMailSession());

in which "getMailSession" returns "java:/Mail". However I'm getting the error below. What is the proper way to lookup the mail session? I have this defined in my mail-server.xml file ...

<attribute name="JNDIName">java:/Mail</attribute>

- Dave

Stack trace follows ...
javax.naming.NameNotFoundException: Mail not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
at javax.naming.InitialContext.lookup(InitialContext.java:409)
at myco.galc.capitol.tours.Emailer.lookupMailSession(Emailer.java:68)
at myco.galc.capitol.tours.Emailer.sendEmail(Emailer.java:55)
at myco.galc.capitol.tours.CapitolToursController.sendEmail(CapitolToursController.java:297)
at myco.galc.capitol.tours.CapitolToursController.sendEmail(CapitolToursController.java:282)
at myco.galc.capitol.tours.CapitolToursController.confirmTourRequests(CapitolToursController.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.el.parser.AstValue.invoke(AstValue.java:170)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:387)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:475)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:756)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:285)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:636)

From forum: JBoss - Dev

Re: Naming over Remoting 3

2009-11-20T11:34:50Z

Let's move future discussion there rather than having two threads going at
once...

- DML

On 11/20/2009 01:22 PM, Scott Stark wrote:

> I added David's and Carlo's comments to the thread Ron had started on
> this topic.
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266823
>
> Carlo de Wolf wrote:
>> Whether it will be ATTCTMVP (tm) or something else ( for example
>> http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/remoting2/src/main/java/org/jboss/ejb3/remoting/endpoint/RemotableEndpoint.java
>> ) remains to be seen. I like
>> http://anonsvn.jboss.org/repos/common/invokablecontainer/trunk/api/src/main/java/org/jboss/ejb3/container/api/Invocation.java
>> with the exception that target is not a first class citizen.
>>
>> AOPRemotingInvocationHandler& Dispatcher definitely need to go. The
>> first, because remoting is not an aspect, the second because it's a
>> singleton with weird SPI (
>> http://fisheye.jboss.org/browse/JBossAS/trunk/ejb3/src/main/org/jboss/ejb3/session/ClassProxyHack.java?r=69926
>> ).
>>
>> Now if you put JNDI, Remoting and proxies in one sentence one
>> requirement is the most important:
>> - all proxies must be transport unaware.
>>
>> So if I bind an EJB into JNDI it doesn't matter whether I lookup through
>> an HTTP(S), IIOP or whatever to get a proxy tied to the connection with
>> which I'm communicating with AS.
>> The same goes for clustering, that is just a virtual connection to a
>> virtual host (/ real cluster).
>>
>> Carlo
>>
>> On 11/19/2009 03:54 AM, Ron Sigal wrote:
>>
>>> So ATTCRMVP (tm) would be the descendant of
>>> org.jboss.aspects.remoting.AOPRemotingInvocationHandler /
>>> org.jboss.aop.Dispatcher ?
>>>
>>> David M. Lloyd wrote:
>>>
>>>
>>>> One observation that's neither here nor there - ALR has been kicking
>>>> around a "back to basics" simple invocation mechanism that should work
>>>> for all Things That Call Remote Methods Via a Proxy (tm), for EJB3 and
>>>> whatever else it may apply to, which opens the possibility to come up
>>>> with a standard Remoting 3 invocation service of some sort.
>>>>
>>>> It looks pretty good to me so far. It lives here:
>>>> http://anonsvn.jboss.org/repos/common/invokablecontainer/trunk/api/
>>>>
>>>> Granted realistically this is going to apply more to what we stick
>>>> *in* JNDI, than how JNDI is itself implemented (which, afaict, -could-
>>>> just be a straight-up Remoting 3 service type, though that'd be a more
>>>> significant departure from the current implementation from what I
>>>> understand of it, than sticking with something more RMI-like).
>>>>
>>>> - DML
>>>>
>>>> On 11/18/2009 07:42 PM, Ron Sigal wrote:
>>>>
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development@...
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development@...
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development@...
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Fwd: JBoss-AS-6.0.x-testSuite-sun16 - Build # 419 - Still Failing!

2009-11-20T11:32:42Z

I have assigned the JBAS-7476 to myself and am working on it.

Shelly McGowan wrote:

> Brian,
>
> I just filed JBAS-7476.
>
> Shelly
>
>
>
> ----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry@...>
> To: "JBoss.org development list" <jboss-development@...>
> Sent: Friday, November 20, 2009 12:11:08 PM GMT -05:00 US/Canada Eastern
> Subject: [jboss-dev] Fwd: JBoss-AS-6.0.x-testSuite-sun16 - Build # 419 - Still Failing!
>
> 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@...
> To: builds@..., bstansberry@...
> 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@...] [JBAS-7473] Configure clustered session manager
> in JBossContextConfig
>
>
> _______________________________________________
> builds mailing list
> builds@...
> https://lists.jboss.org/mailman/listinfo/builds
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development@...
> https://lists.jboss.org/mailman/listinfo/jboss-development
>

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Naming over Remoting 3

2009-11-20T11:22:07Z

I added David's and Carlo's comments to the thread Ron had started on this topic.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266823

Carlo de Wolf wrote:

Whether it will be ATTCTMVP (tm) or something else ( for example 
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/remoting2/src/main/java/org/jboss/ejb3/remoting/endpoint/RemotableEndpoint.java 
) remains to be seen. I like 
http://anonsvn.jboss.org/repos/common/invokablecontainer/trunk/api/src/main/java/org/jboss/ejb3/container/api/Invocation.java 
with the exception that target is not a first class citizen.

AOPRemotingInvocationHandler & Dispatcher definitely need to go. The 
first, because remoting is not an aspect, the second because it's a 
singleton with weird SPI ( 
http://fisheye.jboss.org/browse/JBossAS/trunk/ejb3/src/main/org/jboss/ejb3/session/ClassProxyHack.java?r=69926 
).

Now if you put JNDI, Remoting and proxies in one sentence one 
requirement is the most important:
- all proxies must be transport unaware.

So if I bind an EJB into JNDI it doesn't matter whether I lookup through 
an HTTP(S), IIOP or whatever to get a proxy tied to the connection with 
which I'm communicating with AS.
The same goes for clustering, that is just a virtual connection to a 
virtual host (/ real cluster).

Carlo

On 11/19/2009 03:54 AM, Ron Sigal wrote:

So ATTCRMVP (tm) would be the descendant of
org.jboss.aspects.remoting.AOPRemotingInvocationHandler /
org.jboss.aop.Dispatcher ?

David M. Lloyd wrote:

One observation that's neither here nor there - ALR has been kicking
around a "back to basics" simple invocation mechanism that should work
for all Things That Call Remote Methods Via a Proxy (tm), for EJB3 and
whatever else it may apply to, which opens the possibility to come up
with a standard Remoting 3 invocation service of some sort.

It looks pretty good to me so far.  It lives here:
http://anonsvn.jboss.org/repos/common/invokablecontainer/trunk/api/

Granted realistically this is going to apply more to what we stick
*in* JNDI, than how JNDI is itself implemented (which, afaict, -could-
just be a straight-up Remoting 3 service type, though that'd be a more
significant departure from the current implementation from what I
understand of it, than sticking with something more RMI-like).

- DML

On 11/18/2009 07:42 PM, Ron Sigal wrote:

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



_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development


_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev

Re: Fwd: JBoss-AS-6.0.x-testSuite-sun16 - Build # 419 - Still Failing!

2009-11-20T10:39:31Z

Brian,

I just filed JBAS-7476.

Shelly

----- Original Message -----
From: "Brian Stansberry" <brian.stansberry@...>
To: "JBoss.org development list" <jboss-development@...>
Sent: Friday, November 20, 2009 12:11:08 PM GMT -05:00 US/Canada Eastern
Subject: [jboss-dev] Fwd: JBoss-AS-6.0.x-testSuite-sun16 - Build # 419 - Still Failing!

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@...
To: builds@..., bstansberry@...
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@...] [JBAS-7473] Configure clustered session manager
in JBossContextConfig

_______________________________________________
builds mailing list
builds@...
https://lists.jboss.org/mailman/listinfo/builds
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development@...
https://lists.jboss.org/mailman/listinfo/jboss-development

From forum: JBoss - Dev