class*
ClassRedirects.class*JBossStringBuilder.class*
Why insn't the jbossretro.jar only including java5 classes while
jbossretro-rt.jar the jdk14 classes?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf O
eadis
> Cc: jboss-development@lists.sourceforge.net; Scott M Stark;
> Ryan Campbell; Adrian Brock
> Subject: RE: [JBoss-dev] aop/jbossretro org.jboss.lang.Enum conflict
>
> This jar needs rebuilding from scratch. It is a mess, with
> the classes in the jar twice?
>
> jar -tf
Me, but we have done nothing to start to define a subtree to my
knowledge.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Heiko W. Rupp
> Sent: Wednesday, May 03, 2006 2:43 AM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] SNMP mib subtree
>
>
y 02, 2006 10:14 AM
> To: Scott M Stark
> Cc: Adrian Brock; Ryan Campbell; QA;
> jboss-development@lists.sourceforge.net
> Subject: RE: jboss-head-jdk-matrix Build Failed
>
> On Tue, 2006-05-02 at 11:54 -0500, Scott M Stark wrote:
> > We have to bootstrap the repository wit
Correct.
> -Original Message-
> From: Ryan Campbell
> Sent: Tuesday, May 02, 2006 10:12 AM
> To: Scott M Stark; Adrian Brock
> Cc: QA; 'jboss-development@lists.sourceforge.net'
> Subject: RE: jboss-head-jdk-matrix Build Failed
>
> This is the use c
has a natural mechanism for
bootstrapping its repository by following the dependency and building
the projects as needed by adding a parent project.
> -Original Message-
> From: Adrian Brock
> Sent: Tuesday, May 02, 2006 9:31 AM
> To: Scott M Stark
> Cc: Adrian Brock; Ryan Ca
Message-
> From: Eric Brown
> Sent: Tuesday, May 02, 2006 7:13 AM
> To: Scott M Stark; Adrian Brock
> Cc: Ryan Campbell; QA;
> jboss-development@lists.sourceforge.net; Tom Benninger
> Subject: Re: jboss-head-jdk-matrix Build Failed
>
> > I doubt a complete move is practical g
For the 42 open 4.0.4.GA issues:
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hi
de&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=10030&fi
xfor=12310691
These either need to be in progress this week and done by Monday the 8th
or they will be postponed. Dimi
>
> Ok, I'll do this. If you want to use JDK5 features, we should
> also look at make jboss retro binaries.
>
Yes, I do so we need separate binaries for 14.
> I'll make JBoss-Head build on the JBossMC-1.0.2.GA binaries.
> Besides the bean deployer in varia, only EJB3 is using it
> until JBoss
acts pushed out to the repository.
> -Original Message-
> From: Adrian Brock
> Sent: Tuesday, May 02, 2006 6:41 AM
> To: Scott M Stark
> Cc: Adrian Brock; Ryan Campbell; QA;
> jboss-development@lists.sourceforge.net
> Subject: RE: jboss-head-jdk-matrix Build Failed
&
. Aop and test need to follow suite. Getting the svn repository setup
has been the bottleneck in most migrations.
> -Original Message-
> From: Adrian Brock
> Sent: Tuesday, May 02, 2006 3:14 AM
> To: Scott M Stark
> Cc: Ryan Campbell; Bill Burke; QA;
>
Can we create an svn equivalent to this cvs repository info page:
http://wiki.jboss.org/wiki/Wiki.jsp?page=CVSRepository
Scott Stark
VP Architecture & Technology
JBoss Inc.
---
Using
Ok, this package already is in the jboss-minmal.jar
-Original Message-
From: Clebert Suconic
Sent: Monday, May 01, 2006 9:20 PM
To: Scott M Stark; Tom Elrod
Cc: Dimitris Andreadis; QA; 'jboss-development@lists.sourceforge.net'
Subject: RE: Problem with minimal config in Branc
So what does this mean, that the custom object input stream is not
needed?
-Original Message-
From: Clebert Suconic
Sent: Monday, May 01, 2006 12:49 PM
To: Scott M Stark; Tom Elrod
Cc: Dimitris Andreadis; QA; 'jboss-development@lists.sourceforge.net'
Subject: RE: Problem wi
Why is that? We need to be doing a better job of minimizing cross
package dependencies to allow for cleaner reuse of functionality.
> -Original Message-
> From: Tom Elrod
> Sent: Monday, May 01, 2006 12:33 PM
> To: Scott M Stark
> Cc: Tom Elrod; Dimitris Andreadi
It does not make sense to add the full remoting jar as there is no
dependency on this other than the serialization classes. This comes back
to the fact that org/jboss/invocation needs to be refactored into a
separate legacy remoting jar, and org.jboss.remoting.serialization
included in it or broken
I have not done any checkins on the VirtualFile.java today, but the
current version does have the expansion correct:
/**
* @author [EMAIL PROTECTED]
* @version $Revision: 1.3 $
*/
I would assume this is a svn issue as it does not do expansion by
default:
http://svnbook.red-bean.com/nightly/en
The next iteration of the profile service is in progress based on a day
I spent with Charles going over the admin usecases in more detail. To
finish a real prototype the vdf/vfs/classloader need to exist in some
form.
-Original Message-
From: Adrian Brock
Sent: Friday, April 28, 2006 6:19
If it's ambiguous then a priority has to be established, as well as
being able to explicitly select the factory type.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Max
Rydahl Andersen
Sent: Thursday, April 27, 2006 2:56 AM
To: jboss-development@lists.sou
I think we should be using something like the more flexible like the
java service provider notion used by jaxp and others as the env aware
factory bootstrap:
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service Provider
A simple example test driver:
package util.jar;
import java.util.I
The binaries in the repository have to be treated as releases. As soon a
version is out there you have to consider that its being used and that
any change to it will break existing usage. If 3.2.0.CR2 is just
repacked with different configurations/dependencies I would call it
3.2.0.CR2-jboss or per
D built with 1.4'
> http://jira.jboss.org/jira/browse/JBWS-799
>
> Scott M Stark wrote:
> > This error showing up after updating my 4.0 workspace:
> >
> > 22:15:22,951 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console,
> > warUrl=.../dep loy/jmx-console
t@lists.sourceforge.net
> Subject: Re: [JBoss-dev] jbossws should not be installed into
> jboss-4.0.x ever
>
> The issue is
>
> 'WARs don't deploy in JBoss HEAD built with 1.4'
> http://jira.jboss.org/jira/browse/JBWS-799
>
> Scott M Stark wrote:
> >
This error showing up after updating my 4.0 workspace:
22:15:22,951 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console,
warUrl=.../dep
loy/jmx-console.war/
22:15:23,248 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
--- MBeans waiting for other MBeans ---
ObjectName: jboss.ws:servi
TECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott M Stark
> Sent: Monday, April 24, 2006 9:00 AM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] jboss-4.0 testsuite build fails
>
> I'll look into it.
>
> > -Original Message
Any commons-logging issues need to be fixed, and I'm looking at it.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Anil Saldhana
> Sent: Monday, April 24, 2006 8:59 AM
> To: jboss-development@lists.sourceforge.net
> Subject: Re: [JBoss-dev] jbo
I'll look into it.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Ryan Campbell
> Sent: Sunday, April 23, 2006 1:50 PM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] jboss-4.0 testsuite build fails
>
> I think this er
ge-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Scott M Stark
Sent: Friday, April 21, 2006 4:32 PM
To: jboss-development@lists.sourceforge.net
Subject: RE: [JBoss-dev] javassist version problem
Yes that's it. I guess javassist has been updated and some component is
refere
Yes that's it. I guess javassist has been updated and some component is
referencing it before javassist itself has been synchronized?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ruel
Loehr
Sent: Friday, April 21, 2006 2:28 PM
To: jboss-development@list
No, I only have one in build-thirdparty.xml:
I think the error message really is saying that something else already
wanted javassist 3.1RC2, but that aop wants 3.2.0.CR1. I'll have to look
at the build code I guess.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
I'm having trouble tracking down the cause of this javassist version
problem:
[synchronizeinfo] Checking currentComponentRef:
ComponentRef{id=javassist,name=j
avassist,filename=component-info.xml,location=null,version=3.2.0.CR1,com
patibles
[EMAIL PROTECTED],
version=3.2.0.CR1}],component=null,imp
A given instance of JaasSecurityManager never has its domainCache reset.
Its set only on creation of JaasSecurityManager by the
JaasSecurityManagerService when a lookup does not have an existing
binding. This cannot be seen from the given JaasSecurityManager code
fragment though.
-Original Me
Where are we at in terms of myfaces integration meaning should we be
bundling this version? What about the indicated tomahawk conflicts? Does
this mean we should be bundling that as well?
> -Original Message-
> From: Manfred Geiler [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 18, 2006
Andy does not know win32 exists apparently.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Dimitris Andreadis
> Sent: Monday, April 17, 2006 12:37 PM
> To: jboss-development
> Subject: [JBoss-dev] JAVA_OPTS settings
>
>
> http://jira.jboss.com
Its affecting my jboss-head build
[EMAIL PROTECTED] build]$ export JBOSS_REPOSITORY=http://somehost
[EMAIL PROTECTED] build]$ ant createthirdparty
Buildfile: build.xml
check.inhibit.downloads:
check.proxy:
set.proxy.withoutauth:
set.proxy.auth:
set.proxy:
createthirdparty:
[get] Gettin
-Original Message-
> From: Damon Sicore
> Sent: Friday, April 14, 2006 11:29 AM
> To: jboss-development@lists.sourceforge.net
> Cc: QA
> Subject: Re: [JBoss-dev] Need a head svn/migration death march list
>
> Yes, we need this. The list of tasks is growing as we protot
needing to be broken up better, reduced in priority, etc.
> -Original Message-
> From: Andy Miller
> Sent: Monday, April 17, 2006 7:25 AM
> To: Dimitris Andreadis; Adrian Brock; Scott M Stark; Ivelin Ivanov
> Cc: jboss-development
> Subject: RE: Improving the JBAS JIR
I want to put together a list of tasks that will get head migrated to
maven/svn by the end of this quarter. All wailing and gnashing of teeth
will be ignored. Meaningful input during the definition of the task list
will most likely be accepted, but depends on its inertial drag to the
march.
Can we
JUnit4 is out:
http://prdownloads.sourceforge.net/junit/junit4.0.zip?download
and I'm interested in being able to use this for easier testing. I'm
also interested in evolving our test framework to support our own custom
annotations for aspects like security as mentioned here:
http://www.jboss.com/
;
> Another question,
>
> Which version of cglib are we supposed to be using? I see
> head has 2.1.1 yet 4.0.x has 2.1.2jboss?
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:jboss-
> > [EMAIL PROTECTED] On Behalf Of Scott M Stark
&g
The reason is I don't want inconsistent defaults for bytecode
generation. If this is handled by the integration layers that is fine,
but let's get those layers configured correctly to use javassist by
default.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
I don't want cglib leaking to the client, but if it's only for server
side components the script can look into the server lib dirs to avoid
this.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Jason T. Greene
> Sent: Thursday, April 13, 2006 11:
In terms of backward compatibility, I suppose a jboss-4.0.3SP1 hosted
client of a 4.0.4.GA hosted hibernate component needs to have a cglib
based proxy?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott M Stark
> Sent: Thu
4.0.4 have cgilib in
> jbossall-client.jar
>
> On Thu, 13 Apr 2006 18:58:25 +0200, Scott M Stark
> <[EMAIL PROTECTED]>
> wrote:
>
> > cglib should not be the default proxy framework as of the hibernate
> > 3.2 release. I thought this was the case. Propagation of
I don't see why. That is just creating a derivative work that if
redistributed under the original jar license should be fine.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Bill Burke
> Sent: Thursday, April 13, 2006 10:14 AM
> To: jboss-develo
ev] Should 4.0.4 have cgilib in
> jbossall-client.jar
>
> We also need cglib for wstools, should I just reference
> server/default/lib, or should it be in client somewhere?
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:jboss-
> > [EMAIL PROTECTED]
The jbossall-client.jar needs to have only jboss lgpl content as well.
Throwing in asf licensed classes is a potential legal problem as what
are the redistribution terms of this jar? I have had this argument with
Sacha to no resolution so we should not be introducing an unknown
complexity.
>
cglib should not be the default proxy framework as of the hibernate 3.2
release. I thought this was the case. Propagation of multiple libraries
doing the same thing needs to be cleaned up.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Bill Bur
Only the tag:
cvs checkout -r JBoss_4_0_4_CR2 jboss-4.0.x
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Bill Burke
> Sent: Thursday, April 13, 2006 9:39 AM
> To: Jboss-Dev
> Subject: [JBoss-dev] how to checkout tagged 4.0.4cr2?
>
> Do you have
I'm trying to understand the full implication of the intellij
synchronization on non-final fields warning, which has this description:
This inspection reports instances of synchronized statements where the
lock expression is a non-final field. Such statements are unlikely to
have useful semantics,
jbossws1.0 should be a final release. I think the only thing holding
back jbossretro from a final release is feedback on the efficacy based
on the current jbossws14 in 4.0.4CR2.
> -Original Message-
> From: Dimitris Andreadis
> Sent: Wednesday, April 05, 2006 3:33 AM
> To: jboss-developm
We have to separate out jbossxb because of the jbossws dependency. This
is already being integrated via a binary and that is all that needs to
be done for the 4.0.4.GA release. All of the other breakup of common is
a future thing.
> - Breakage of jboss commons. Is this the right time, or
> shoul
Right. Every jira issue with a documentation check box should have an
entry section in the highlights section of the release notes. Every jira
issue with a compatibility check box should have an entry in the
compatibility section.
> -Original Message-
> From: Adrian Brock
> Sent: Wednesda
jboss.net module can't be removed due to the wonderful cvs modules
behavior. I don't want a jboss-4.0.xv2 module alias definition.
>
> - JBoss.Net is not even included in the docs/examples now.
> Should it be removed from the 4.0.x module checkout?
>
--
I do have to question why the class loader is destroyed before all
deployments are though. I'll look into that as part of the JBAS-3063
issue.
> -Original Message-
> From: Scott M Stark
> Sent: Wednesday, April 05, 2006 10:24 AM
> To: Adrian Brock
> Cc: Rajesh Ra
I'll create a jira issue for the class loader behavior.
> -Original Message-
> From: Adrian Brock
> Sent: Wednesday, April 05, 2006 10:16 AM
> To: Scott M Stark
> Cc: Rajesh Rajasekaran; QA; jboss-development@lists.sourceforge.net
> Subject: RE: jboss-4.0-testsui
; Dimitris
> Andreadis; Emmanuel Bernard; [EMAIL PROTECTED];
> jboss-development@lists.sourceforge.net;
> [EMAIL PROTECTED]; Kabir Khan; Ryan Campbell; Ruel Loehr;
> Scott M Stark; Thomas Diesler; Tom Elrod
> Subject: RE: jboss-4.0-testsuite Build Failed
>
> The "all&quo
An undeployed class loader should probably still delegate to its parent
if it does not have a repository?
> -Original Message-
> From: Adrian Brock
> Sent: Wednesday, April 05, 2006 9:42 AM
> To: Scott M Stark
> Cc: Rajesh Rajasekaran; QA; jboss-development@lists.
javadoc is generated in all, but its completely upto the module all
target definition to make this distinction. The all target should depend
on most and add to it.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Tom Elrod
> Sent: Wednesday, April
Yes, we should be defaulting to a single node, unclustered jboss cache
rather than having to supply yet another thirdparty jar to handle the
baseline cache.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott Marlow
> Sent: Monday, April 03, 2
We can't be relying on classes from the sun.* package namespace.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Ruel Loehr
> Sent: Monday, April 03, 2006 10:03 AM
> To: jboss-development@lists.sourceforge.net
> Cc: Jason T. Greene; Thomas Diesl
The current build-distr.xml looks to have been corrected. I really doubt
that the crusecontrol detection of a quiet period of activity is either
broken or not long enough as these transient build breaks happen often.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTE
4.0.4 sections have been added to:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossReleaseNotes
http://wiki.jboss.org/wiki/Wiki.jsp?page=404UpgradeIssues
Scott Stark
VP Architecture & Technology
JBoss Inc.
--
jbossws/jbossws14 have been marked as compatible with 1.0.4jboss as
well.
> -Original Message-
> From: Adrian Brock
> Sent: Friday, March 31, 2006 9:36 AM
> To: Scott M Stark
> Cc: Dimitris Andreadis; jboss-development@lists.sourceforge.net; QA
> Subject: RE: JBoss-4.0
I build ok with both jdk5/jdk1.4.2 last night. Let me try another box/workspace
to validate if something is missing.
> -Original Message-
> From: Dimitris Andreadis
> Sent: Friday, March 31, 2006 6:13 AM
> To: 'jboss-development@lists.sourceforge.net'; QA
> Subject: JBoss-4.0.4.CR2 toda
Already dealt with, see:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=80196
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Bill Burke
> Sent: Friday, March 31, 2006 8:36 AM
> To: jboss-development@lists.sourceforge.net
> Subject: Re
I don't see any runtime dependency on javassist in the jbosstretro
translated output, but the component-info.xml declares a dependency:
http://www.jboss.org";
description="JBossRetro is a weaver which will
transform Java SE 1.5 byte code to its Java 1.4
equivalen
If Alexey does not reply by tomorrow I would take the current jboss-head
code and make a jbossxb-1.0.0.CR3 release. I don't know how this is
being built since this has not been broken out yet. For the 4.0.4.GA the
common module needs to be broken up into a separate projects with those
jars released
The class has been renamed to org.jboss.lang.EnumImpl, and I moved the
JBossRetro_1_0_0_CR1 tag on the updated files so can you rebuild the
current 1.0.0.CR1 jars.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Ryan Campbell
> Sent: Wednesday, M
Ok. A new jbossws14 binary will need to be created from the updated
jbossretro jars.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Adrian Brock
> Sent: Wednesday, March 29, 2006 1:43 PM
> To: jboss-development@lists.sourceforge.net
> Subject: R
There is a conflict between two org.jboss.lang.Enum objects, one from
aop and another from jbossretro. There should only be one. The
jbosstretro version is more complete, but is not designed to be usable
in js2e1.4 without being translated.
How are we going to resolve this?
TECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott M Stark
> Sent: Wednesday, March 29, 2006 10:19 AM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] Why is all of this stuff in the
> jbossas build-thirdparty?
>
> I have removed all use
I have removed all use of the gnu.regex from 4.0/head. This includes the
new jms selector code which was copied from jbossmq.
> -Original Message-
> From: Scott M Stark
> Sent: Tuesday, March 28, 2006 7:32 PM
> To: 'jboss-development@lists.sourceforge.net'
> Sub
If the installer is built as it is for the 4.0.x dist with only the
aspects, ejb3 and ejb3x modules built with jdk5, the tests fail because
the ejb3/build-test.xml client.classpath is referring to
${jboss.dist}/client/jbossall-client.jar, but this jar does not contain
the ejb3 classes. It cannot fo
I'm seeing this org.jboss.test.jbossmq.test.ExpiryDestinationTestCase
fail due to timing issues? The test is failing because the dlq count is
not 2000. Its both below and above. Is this a reliable test?
Scott Stark
VP Architecture & Technology
JBoss Inc.
x
Looks ok now.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Clebert Suconic
> Sent: Tuesday, March 28, 2006 8:23 PM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] Why isn't server building?
>
> It should be fixed now
The following use it:
[EMAIL PROTECTED] jboss-4.0.x]$ find . -name build.xml -exec grep -l
gnu.regexp {} \;
./aspects/build.xml
./jmx/build.xml
./messaging/build.xml
./testsuite/build.xml
./varia/build.xml
I would like to replace these uses with the java.util.regex package in
4.0.x+ since j2se1.4
I want to drop the unsupported/unmaintained loadbalancer.sar from the
varia module.
Scott Stark
VP Architecture & Technology
JBoss Inc.
---
This SF.Net email is sponsored by xPML,
So is there a runtime dependency on something or is this only compile
time?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Brian Stansberry
> Sent: Tuesday, March 28, 2006 5:48 PM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JB
My common, server, and remoting thirdparty are in synch with the 4.0
branch but there is a conflict:
[javac]
C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv
okerInterceptor.java:285: incompatible types
[javac] found :
org.jboss.remoting.serialization.impl.jboss.Local
Where are all of these thirdparty elements being used such that they are
specified here? In particular, what is using the * ones?
*
*
*
*
*
* Can this be
dropped from jbossxb?
*
Ok, I think Brian already addressed those.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Emmanuel Bernard
> Sent: Tuesday, March 28, 2006 2:39 PM
> To: jboss-development@lists.sourceforge.net
> Subject: Re: [JBoss-dev] Do a clean build before
I'm working with the ejb3 tests as part of the installer testing. I
don't intend to fix all of them but if there are obvious mistakes I'll
try to fix them.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Dimitris Andreadis
> Sent: Tuesday, March
Start doing a clean build before committing any changes to
build-thirdparty.xml to avoid this consistent problem:
[synchronizeinfo] Checking currentComponentRef:
ComponentRef{id=jboss/remoting,n
ame=jboss/remoting,filename=component-info.xml,location=null,version=1.4
.0_final
,[EMAIL PROTECTED],
v
l
Burke; Brian Stansberry; Emmanuel Bernard;
jboss-development@lists.sourceforge.net; [EMAIL PROTECTED]; Kabir Khan; QA;
Ryan Campbell; Ruel Loehr;
Scott M Stark; Thomas DieslerSubject: jboss-4.0-testsuite Build
FailedImportance:
High
View results here -> http://cruisecontrol
: 3.2.0.CR1
but it is also required to be compatible with:
[EMAIL PROTECTED], version=3.1RC2}]
by: jboss/aop
> -Original Message-
> From: Ryan Campbell
> Sent: Monday, March 27, 2006 12:57 PM
> To: Scott M Stark; QA; 'jboss-development'
> Subject: RE: third
I'm working on the installer stuff now.
> -Original Message-
> From: Dimitris Andreadis
> Sent: Monday, March 27, 2006 8:29 AM
> To: QA; jboss-development
> Cc: Thomas Diesler; Tom Elrod; Bill Burke; Brian Stansberry;
> Adrian Brock; Clebert Suconic; Scott
)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> -Original Message-
> From: Scott M Stark
> Sent: Monday, March 27, 2006 12:51 PM
> To: QA; 'jboss-development'
> Subje
[synchronizeinfo] [10]: javassist
[synchronizeinfo] Checking currentComponentRef:
ComponentRef{id=javassist,name=j
avassist,filename=component-info.xml,location=null,version=3.1RC2,compat
ibles=[C
[EMAIL PROTECTED],
version=3.1RC2}],component=null,importingComponent=Com
[EMAIL PROTECTED]/aop
atts=
t; On Sat, 2006-03-25 at 11:16 -0600, Scott M Stark wrote:
> > Is the JBAS-2973 (ConcurrentReaderHashMap iterators returning null)
> > issue worth a 3.2.8.SP2 after the 4.0.4.CR2?
>
> Not really. I am dubious that it is a real problem with the
> current code using Oswego.
Is the JBAS-2973 (ConcurrentReaderHashMap iterators returning null)
issue worth a 3.2.8.SP2 after the 4.0.4.CR2?
Scott Stark
VP Architecture & Technology
JBoss Inc.
---
This SF.Net e
net'Subject: RE: Adding
javassist to server/default/lib
This brings up a
question of the javassist version. AOP only declares compatibility with
3.1RC2. Can this be upgraded to 3.2.0.CR1?
From: Ryan
Campbell Sent: Friday, March
24, 2006 1:51 PMTo:
Scott
Its only integrated when building with j2se1.4.x which is
why I was not seeing it. Can you trigger another testsuite run as I have not
seen one since I have updated the jacc configs.
From: Ryan Campbell Sent: Thursday,
March 23, 2006 5:44 PMTo: Scott M Stark; '[EMAIL PROT
AM
> To: Scott M Stark; Bill Burke
> Cc: QA; jboss-development@lists.sourceforge.net
> Subject: RE: JACC (ejb 3) - WAS RE: jboss-4.0-testsuite Build
> Completed With Testsuite Errors
>
> I didn't commit the Policy.setPolicy() stuff if that's what
> you mea
Where is the ejb3 code that sets up the jvm Policy instance as I would
like to review how its being done.
> -Original Message-
> From: Kabir Khan
> Sent: Friday, March 24, 2006 5:02 AM
> To: Bill Burke; Scott M Stark
> Cc: QA; jboss-development@lists.sourceforge.
Class-Path entries effect deployment?
>
> Can you take a look at the forum post? It looks like the
> Class-path entries are being scanned. Not sure how that is
> possible since di.url is being used as the scanned thing.
>
> Scott M Stark wrote:
> > The referenced
; From: Kabir Khan
> Sent: Friday, March 24, 2006 5:02 AM
> To: Bill Burke; Scott M Stark
> Cc: QA; jboss-development@lists.sourceforge.net; Kabir Khan
> Subject: JACC (ejb 3) - WAS RE: jboss-4.0-testsuite Build
> Completed With Testsuite Errors
>
> I've taken a look
rather than the aop deployer due to the jbossretro, hibernate, etc dependencies
not related to aop. I'm not seeing the jbossretro-rt.jar anywhere in the current
4.0 build, and my workspace is up to date. Has this been integrated into the
dist structure yet?
From: Scott M Stark Sent: Thu
CTED]; QA; Ryan Campbell; Ruel
Loehr; Scott M Stark; Thomas
DieslerSubject: jboss-4.0-testsuite Build
Completed With Testsuite ErrorsImportance:
High
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=log20060323142936
The referenced jars are added to the DeplomentInfo's class loader
classapth. Any other standard class loaders such as URLClassLoaders that
are created for the jar will also pickup these as part of their
classpath.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
101 - 200 of 4685 matches
Mail list logo
