gs in jboss-j2ee.jar since we want
to provide a layer that works in all environments including those
that have their own j2ee jars.
On Wed, 2006-01-04 at 19:52, Scott M Stark wrote:
> I see that the security module has become dependent on the transaction
> module to support the suspention of th
So the simplest fix
to this issue:
http://jira.jboss.com/jira/browse/JBAS-2687
would seem to be to
simply set the TCL to the IdleRemover class loader. More generally we should
move this to a work manager task no?
Scott StarkVP Architecture &
Technology
JBoss I
Dimitris is going to be driving a finalization of the legacy 3.2.8
release. There still are 11 outstanding issues with several unassigned
so he will be contacting the reporters and following up here to get them
assigned.
The big outstanding integration issue is the targeted binary
compatibility b
Agree on the scheduler.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Adrian Brock
> Sent: Thursday, January 19, 2006 8:20 AM
> To: jboss-development@lists.sourceforge.net
> Subject: Re: [JBoss-dev] JBAS-2687
>
> The IdleRemover.class.getClass
It depended on JBAS-2547. I need to review the associated unit test and
see if its possible to implement this in 3.2. There is a different
run-as principal behavior in 3.2 and no notion of additional run-as
roles that would need to be backported as well to fully match the 4.x
behavior and I don't k
So all of the retroweavers to date rely on the java.util.concurrent
backport to jdk1.4 (http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/)
for mapping the jdk5 concurrent util classes. I guess we need to validate this
library and deprecate the current Oswego
concurrent package
t: Sunday, January 15, 2006 7:46 PM
> To: Bill Burke
> Cc: Scott M Stark; QA; Adrian Brock; Bill Decoste;
> jboss-development@lists.sourceforge.net; Kabir Khan; QA; Ruel
> Loehr; Thomas Diesler
> Subject: Re: ejb3-4.0-testsuite Build Failed
>
> I should restate. The HA-JND
test has completed and has
been undeployed. One gc root is the java.util.TimerThread task queue.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott M Stark
> Sent: Saturday, January 21, 2006 2:17 PM
> To: Bill Burke
>
[mailto:[EMAIL PROTECTED] On
> Behalf Of Scott M Stark
> Sent: Saturday, January 21, 2006 10:12 PM
> To: jboss-development@lists.sourceforge.net; Bill Burke
> Subject: RE: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed
>
> So after profiling this the problem
ra/browse/JBAS-2205
> > >
> > >>From the cvs commit, it looks like he did this because the
> > > old implementation didn't have a "shutdown" method:
> > >
> http://anoncvs.forge.jboss.com/viewrep/JBoss/jboss-common/src/main/o
> >
We need agreement from all projects to accept and adhere to the version
conventions discussed here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75175
Scott Stark
VP Architecture & Technology
JBoss Inc.
-
;
jboss-development@lists.sourceforge.net;
Kabir Khan; QA; Ruel Loehr; Scott M
Stark; Thomas Diesler
Subject: ejb3-4.0-testsuite Build
Failed
Importance: High
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060122131732
BUILD
FAI
It’s a bug, but I only see the MILLISECOND
value being used. I don’t see that javax.management.j2ee.statistics.TimeStatistic
has these constants in the 4.0 branch, so where are you seeing that?
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis
Sen
I would suspect that the tests simply asserted that someone could be
denied access. This is a general failing in the tests I see written.
Tests only assert that the expected good things happen. There are not
enough tests written to validate that bad behaviors are also constrained
to expected and re
What happened to the webex?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julien Viet
Sent: Friday, January 27, 2006 4:21 PM
To: jboss-development@lists.sourceforge.net
Subject: Re: [JBoss-dev] Maven2 technical discussion
We had a presentation of Maven
I’m working through getting these in
synch.
From: Ryan Campbell
Sent: Saturday, January 28, 2006
9:51 AM
To: jboss-development@lists.sourceforge.net;
Scott M Stark
Subject: RE: jboss-4.0-jdk-matrix
Build Failed
Strange errors on the build machine
(checking these), but
Its building for me now.
From: Ryan Campbell
Sent: Saturday, January 28, 2006
9:51 AM
To: jboss-development@lists.sourceforge.net;
Scott M Stark
Subject: RE: jboss-4.0-jdk-matrix
Build Failed
Strange errors on the build machine
(checking these), but I’m getting the
What tests depend on this login module? As
I remember only the run-as capability needed to augment the roles and this does
not require a login module to do this.
From: Thomas Diesler
Sent: Monday, January 30, 2006
4:16 AM
To: Scott M Stark
Cc: 'jboss-develo
Sent: Monday, January 30, 2006
4:52 AM
To: Scott M Stark
Cc: 'jboss-development@lists.sourceforge.net'
Subject: RE: Restore
DeploymentRolesLoginModule
There are various
tests that define a role mapping in sun-ejb-jar.xml. These roles are mapped to
jboss.xml
We had this discussion in a forum and came to no conclusion as to how to
ensure these are kept in synch. What is clearly needed is running
portions of the testsuite against the installer generated
configurations. Some work to run the installer in a command line mode
will be needed for this.
-O
DeploymentRolesLoginModule has to be in this login-config.xml section
is the question.
From: Thomas Diesler
Sent: Monday, January 30, 2006
5:17 AM
To: Scott M Stark
Cc: 'jboss-development@lists.sourceforge.net'
Subject: RE: Restore
DeploymentRolesLoginModule
For this to be
Adrian,
Have you had a chance to synch up with Kabir on the MC/AOP
unification work yet?
I browsed through the EJB3StandaloneBootstrap and embedded ejb3 usage of the mc to see what extent the mc is being used. In browsing through the conf/embedded-jboss-beans.xml for the mc config, I did not see anything related to the ejb3 container or aop layer to load the conf/ejb3-interceptor
right, the new architecture can be used as an
abstraction for projects that need to work in both JBoss4 and MC.
Man, I want to help prototype this stuff. I was about to do it for the
last EJB3 release, but I ran out of time. I'll want to jump in and help
after I finish the EJB3 book.
L
pment@lists.sourceforge.net
Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation
Scott M Stark wrote:
> How can the scanClasspath() step be optimized/skipped in say an
embedded
> ejb3 project in jbosside where the data obtained during the scan was
> written out in an optimized
I still think we need a jmx object name alias registry to wean off of
the objectnames to simple, purpose oriented names. This would have to be
integrated as an aspect on top of the mbeanserver/registry.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adria
again a prototype) and POJOs to allow
aspects to be configured via DI in the MC.
Bill did help me with some pointcut definition enhancements
to implement MessageEndpoint properly.
I'm hoping if I do this for something less esoteric than JCA
then I will get some feedback ;-)
On Tue, 2006-
@lists.sourceforge.net
Cc: Scott M Stark
Subject: 3.2.x / 4.0.x compatibility
One of the differences I see in the 2 branches, is the useFullHashMode:
org.jboss.invocation.MarshalledInvocation
/** A flag indicating if the */
static boolean useFullHashMode = false;
Which was added around 3.2.4
http
Also make sure the jira issue number is used in the check in all
branches so that the branches the changes have been committed to are
clear from the issue version control tab.
-Original Message-
From: Scott M Stark
Sent: Thursday, February 02, 2006 3:54 PM
To: 'jboss-develo
Make sure you include the jira issue number for any checkins related to
a jira issue so that the changes associated with the issue show up in
the Version Control tab of the issue. It also aides in correlating cvs
log messages with jira issues.
I have been asked to also remind you that a useful comment also be
included in each change set since there can be a disconnect between what
shows up in the jira issue vs the individual file changes.
Scott M Stark wrote:
> Make sure you include the jira issue number for any checkins related
to
So I have to introduce a proxy for a javax.net.SSLServerSocket
which is an abstract class and so have to use cglib or javassist. I see some
proxy working in the head javassist, but this is not in the 4.0 branch version.
We also don’t bundle javassist with 4.0 currently. I assume we would
ra
It was the only way I found to implement a timeout behavior that had a
chance of working when there were uncooperative tasks. See the
org.jboss.test.util.test.
ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
example.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAI
I have a need to externalize some configuration on a new security
related interceptor and don't want to propagate the old XmlLoadable
interface, even though it's the only way to do this currently. I could
adapt some of the service xml support configuration mechanisms like
serialDataType="javaBean |
serialDataType="javaBean".
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Scott M Stark
Sent: Sunday, February 05, 2006 1:05 PM
To: jboss-development@lists.sourceforge.net
Subject: [JBoss-dev] Legacy xml config parsing
I have a need to externalize some con
The internal api used by the jdk looks to have been updated
to allow for 32k file paths rather than the current 255 char limit:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182812
Somehow we seem to have missed synching the javax.xml.bind.JAXBException
class serialVersionUID up with the j2ee1.4 value when we aligned these
in 4.0.2.
WARNING: No explicit serialVersionUID:
ClassVersionInfo{serialVersion=4092921986583236256,
hasExplicitSerialVersionUID=false, name=javax.xml.bi
I’m seeing some incompatible serial version uid
changes in the latest antlr, but I don’t know if antlr exceptions every
leak to users outside of the vm such that this is an issue. Do the ql grammar
exception get exposed or are they always converted to a hibernate exception?
serialVersio
javax.xml.bind.* and jaxb are not part of j2ee1.4 even though the ri
happens to include them so this is actually fine. The serialVersionUID
has been set to the j2ee1.4 value.
-Original Message-
From: Scott M Stark
Sent: Monday, February 06, 2006 11:27 AM
To: jboss-development
I have not seen any outcry over the version convention thread so I have
updated the product version page to summarize the conclusion reached.
Getting projects aligned to this convention is something all leads need
to work on.
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning
xx
It cannot be resolved as a version in between a Beta and GA release
using the osgi bundle version comparision as discussed in this thread.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75175
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Beha
file should be where a project makes version changes
and this should just propagated to artifacts based on the build tools.
> -Original Message-
> From: Max Andersen
> Sent: Tuesday, February 07, 2006 10:14 AM
> To: Scott M Stark; Christian Bauer; development Hibernat
nday, February 06, 2006 11:53 AM
> To: Scott M Stark; jboss-development@lists.sourceforge.net;
> Hibernate development
> Subject: Re: [Hibernate] Do antlr exception leak to users?
>
> On Mon, 06 Feb 2006 20:49:08 +0100, Scott M Stark
> <[EMAIL PROTECTED]>
> wrote:
&
;
throw new Xception(msg);
}
> -Original Message-
> From: Max Andersen
> Sent: Tuesday, February 07, 2006 10:34 AM
> To: Scott M Stark; jboss-development@lists.sourceforge.net;
> Hibernate development
> Subject: Re: [Hibernate] Do antlr exception leak to users?
>
ECTED] On
> Behalf Of Scott M Stark
> Sent: Tuesday, February 07, 2006 10:22 AM
> To: Max Andersen; Christian Bauer; development Hibernate;
> [EMAIL PROTECTED]
> Cc: jboss-development@lists.sourceforge.net
> Subject: RE: [Hibernate] Release naming conventions
>
> Any place the vers
> fixing the antlr exception svuid won't help us if the client
> is using an older version, right ?
>
It will if the serialVersionUID is set to the implicit value from the
previous version. This can be done if the version is still serializable
compatible.
> calling printStackTrace() on every exc
t;:20060208T09
SUMMARY:Accepted: [JBoss-dev] Maven2 discussion
UID:04008200E00074C5B7101A82E008905F2284492BC601000
010007AD3E23387F0E54BBDA4311EDA6FC1FC
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE;CN="Scott M Stark
":MAILTO:[EMAIL PROTECTED]
ORGANI
> which it isn't afaik. the antlr version started to include
> more data in the exception over time.
>
Including additional data is not an incompatible serialzable change
generally. Its optional data that will be ignored and cannot affect the
legacy implementation.
> >> calling printStackTrace(
used for the ejb3 query language parser. Antlr
should not be a required jar in the jboss client jars for ejb3 usage.
> -Original Message-
> From: Steve Ebersole
> Sent: Wednesday, February 08, 2006 6:52 AM
> To: Max Andersen; Scott M Stark;
> jboss-development@lists.source
So after listening to the Maven2 webinar yesterday and talking with
Ryan, Ruel and Steve E as a lead, I don't see a good reason why we
shouldn't look to using maven2 as the core of the jbossbuild. The two
outstanding proof of concept issues I asked Ruel to look at are:
1. Source in the repository.
Great.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Bill Burke
> Sent: Thursday, February 09, 2006 7:54 AM
> To: jboss-development@lists.sourceforge.net; Tim O'Brien
> Subject: Re: [JBoss-dev] On the edge of the Maven cliff
>
> I've put a Ma
So this is item 3 on Ruel's list to look into. It's related to item 1.
as I explained its usage to Ruel.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Adrian Brock
> Sent: Thursday, February 09, 2006 8:14 AM
> To: jboss-development@lists.sourc
Yes, leveraging a community of people interested in builds vs jboss
resources makes more sense.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Bill Burke
> Sent: Thursday, February 09, 2006 8:21 AM
> To: jboss-development@lists.sourceforge.net
I don't see stabilization happening though as we still have the pending
maven move and restructing to have a common module structure and
potentially splitting up existing projects to better match the maven
ideal. Let's just define how we want commons broken up with Ruel in the
loop so he can chase
Part of the problem is everyone running around trying to get work done
on multiple branches while Ruel is trying to baby step new build setups
in. I think we need to get to a point where we just say head is going to
be refactored and potentially broken for an extended period of time
while we refact
Friday, February 10, 2006 5:15 AM
> To: Scott M Stark
> Cc: jboss-development@lists.sourceforge.net; QA
> Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On
> the edgeoftheMaven cliff
>
> Ironically, one of the problems I am trying to solve will be
> made worse by t
ginal Message-
> From: Adrian Brock
> Sent: Friday, February 10, 2006 6:46 AM
> To: Scott M Stark
> Cc: jboss-development@lists.sourceforge.net; QA
> Subject: RE: Ongoing build changes: was RE: [JBoss-dev] On
> theedgeoftheMaven cliff
>
> On Fri, 2006-02-10 at 08:39, Scott
Let's do that. Do you want to couple this to maven? It would help Ruel I
suppose.
> -Original Message-
> From: Adrian Brock
> Sent: Friday, February 10, 2006 9:34 AM
> To: Scott M Stark
> Cc: jboss-development@lists.sourceforge.net; QA
> Subject: RE: Ongoin
, February 11, 2006 3:48 AM
To: Scott M Stark
Cc: jboss-development@lists.sourceforge.net; QA
Subject: RE: Ongoing build changes: was RE: [JBoss-dev]
OntheedgeoftheMavencliff
On Sat, 2006-02-11 at 04:33, Adrian Brock wrote:
> On Fri, 2006-02-10 at 13:28, Scott M Stark wrote:
> > Let's d
ved into svn
Damon?
>>
>> -Original Message-
>> From: Adrian Brock
>> Sent: Saturday, February 11, 2006 3:48 AM
>> To: Scott M Stark
>> Cc: jboss-development@lists.sourceforge.net; QA
>> Subject: RE: Ongoing build changes: was RE: [JBoss-dev]
>> Ontheedgeo
independently versioned subcomponents.
Maven uses it here: http://svn.apache.org/repos/asf/maven/trunks/
Jakarta Commons uses it here:
http://svn.apache.org/repos/asf/jakarta/commons/trunks-proper/
-Original Message-
From: Adrian Brock
Sent: Saturday, February 11, 2006 3:
ly running at a load of
10 on a single proc machine (or something close). Eric?
On Feb 11, 2006, at 2:38 PM, Scott M Stark wrote:
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download
hout a standard location for thirdparty how do we share
> the Eclipse project descriptors?
> Although, I believe Maven has a task to generate them locally
> rather than sharing them, I don't currently know how to do this.
>
> On Sat, 2006-02-11 at 16:03, Scott M Stark wrote:
y.
>
> I still don't know how to make this compile within Eclipse?
> i.e.
> Without a standard location for thirdparty how do we share
> the Eclipse project descriptors?
> Although, I believe Maven has a task to generate them locally
> rather than sharing them, I don&#x
Its not true that the entire cvs repository is tagged when a release is
done. There are numerous cvs module aliases encompassing different
release components. In a large aggregation of components such occurs in
jbossas, the jbossas cvs module alias is tagged, and many components
come in as binaries
We are mixing several issues here though.
1. Ruel's attempt to replicate the build using maven was a question as
to whether maven could handle a screwed up build structure.
2. Since this is not ideal and maven has an even stricter notion of a
source tree/per artificat, should the build be restruct
So I tried using this tomcat svn repo in both eclipse using the
http://subclipse.tigris.org/ plugin and in intellij 5.1.
http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x
I found a line referring to the "people wearing tin hats" in one of the
tomcat files and wanted to see who the commedia
14, 2006 10:30 PM
> To: jboss-development@lists.sourceforge.net
> Subject: Re: [JBoss-dev] So does svn really work in the ides?
>
> Scott,
>
> see below, Subclipse is working just fine.
>
> --- Scott M Stark <[EMAIL PROTECTED]> wrote:
> >
> > Us
Huh? We are propagating relationships across jvm boundaries? That does
not make sense.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Clebert Suconic
> Sent: Wednesday, February 15, 2006 1:22 PM
> To: jboss-development@lists.sourceforge.net
> Su
Title: Re: [JBoss-dev] client libraries on EJB3
Can this enhanced proxy be replaced during
serialization to avoid this? If these classes cannot be used in a functional
manner by a client, they should not be exposed to the client. Just replace the
proxy with a wrapper around the lazy load exce
Title: Re: [JBoss-dev] client libraries on EJB3
I'm asking if we can replace the proxy with one that throws
the lazy loading exception on any method access without leaking dependencies on
the proxy related classes.
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Title: Re: [JBoss-dev] client libraries on EJB3
For the remote proxies and associated aspects yes, but
I don't want proxy stuff leaking for no good reason. A proxy that can only be
used to cause an exception to be thrown is not a good reason to introduce a new
library dependency on the client
But here we are talking about what exists after the object in question
has been serialized outside of the jvm. Does what your talking about
still apply in that situation? Regardless, I think this discussion just
further pushes for a unified javassist based proxy framework sometime
before ejb3 is fi
If your not subscribed to the [EMAIL PROTECTED]
(see how to subscribe here
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossDeveloperChannels) then
you missed the explosion of JBossESB threads Mark Little has started.
See the following forum for the threads:
http://www.jboss.com/index.html?module=bb&o
ity to still
> need access to the proxy generation library on
> de-serialization. This is because it is *possible* to have a
> collection containing proxies in the case of many-to-many
> associations.
>
> -Original Message-
> From: Scott M Stark
> Sent: Thursday,
These two issues currently assigned to Tim:
http://jira.jboss.com/jira/browse/JBAS-1434
http://jira.jboss.com/jira/browse/JBMESSAGING-170
have been waiting for quite a while. Are we going to be able to get
these resolved for the 4.0.4.GA release due out in a month?
So in going through the outstanding jira issues for jbas, there are a
lot of old cmp2 issues. We have never really made a decision on whether
we are going to try to move the cmp2 model onto an ejb3/hibernate based
implementation. That would seem to be the best migration and support
strategy.
xxx
ary 17, 2006 3:08 PM
> To: Scott M Stark; Ryan Campbell; Dimitris Andreadis
> Cc: jboss-development@lists.sourceforge.net; QA
> Subject: RE: 3.2.8 Client -> 4.0.x Compatibility
>
> I spent some time today with this issue. I just want to throw
> some ideas to fix this.
>
&
its choosing the right hash codes for the target server. You really need
to be able to build the hash map based on the connection.
From: Clebert Suconic
Sent: Friday, February 17, 2006
10:51 PM
To: Scott M Stark; Ryan Campbell; Dimitris Andreadis
Cc: 'jboss-development@lists.sourcef
The ejb3 integration issues is something I will be looking at
immeadiately after the 4.0.4.GA release. The 4.0.5.GA target is just
when this has to be done by. Progress towards this will be showing up in
4.0.5.CR1.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
Should we drop this warning message? Its actually irrelevant since the
default compilation mode for jsps is to use the eclipse version. What is
javassist using for compilation?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> faisalaslam
> Sent: S
With a fresh update and clean build there is some port conflict going
on:
10:28:44,790 WARN [ServiceController] Problem starting service
jboss.remoting:s
ervice=JMXConnectorServer,protocol=rmi
java.rmi.server.ExportException: Port already in use: 1090; nested
exception is:
java.net.BindE
versions by casting the listener
to a RMINotificationListener. These are MBeanServerConnection methods
and should be delegated to the mbeanServer.
> -Original Message-
> From: Clebert Suconic
> Sent: Sunday, February 19, 2006 3:03 PM
> To: Scott M Stark; Dimitris Andreadis
Dimitris, remind me why removing xalan is a problem. I'm not getting it
from the discussion thread associated with this JBAS-2073 issue. From
the TransformerFactory javadoc:
public static TransformerFactory newInstance()
throws TransformerFactoryConfigurationError
Obtain a new instance of
So the problem is lack of encapsulation of the essentially global
org.apache.xalan.processor.TransformFactoryImpl name due to the
proliferation of the xalan distribution. One should be able to work
around this by introducing a
org.apache.xalan.processor.TransformFactoryImpl2 that loaded the
org.apa
This type if info on dependecies (the license needs to be added as well
and the project url cannot be empty) is what every project in
labs.jboss.org should have:
http://groovy.codehaus.org/dependencies.html
This should be generated from the project thirdparty dependency
declarations.
xxx
> The org.apache.xalan.processor.TransformFactoryImpl visible
> through the TCL, for a non-scoped deployment, wouldn't be
> again the JDK bundled xalan, since this is loaded with the
> Bootstrap CL? (testing my CL knowledge here :)
>
Not necessarily because the org.apache.* is not a jdk core cl
Gavin made me look at groovy for things like closures, and the groovy
site shows a pervasive set of changes in the core jdk classes to support
things like groovy.lang.Range, groovy.lang.Closure:
http://groovy.codehaus.org/groovy-jdk.html
but the associated jsrs don't seem far along:
http://www.jc
The question is where the the xml-apis.jar come from then? It should not
include a TransformerFactory if its not from the xalan distribution
which is what I suspect. The origin of the xml jars needs to be
validated and if the xerces distribution defaults to configuring a
TransformerFactory, that sh
This is probably a jaxp requirement to not subset the apis. The next
question is whether the xml-apis.jar is needed. Is jdk1.4.x at jaxp 1.2?
The xerces 2.7.x release supports jaxp 1.3.
The potential problem with doing this is are there dependencies between
the javax.xml.transform.* classes and th
The more I think about it the more I doubt this is legal for a java ee
distribution. If we are bundling jaxp 1.3, we need it to be the complete
1.3 set of apis and we would just have to patch the TranformerFactory to
do the right thing, whatever that is.
> -Original Message-
> From: [EMAIL
No, this should not be installed in the server build structure. It needs
to be integrated into a testsuite/src/resources/test-configs that
jbossws uses. I created the following build forum post on this.
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3925623#3925623
> -Original Messa
Setting this via a system property cannot be done as this is a global
override. We could simply externalize the default factory name to an
attribute of the jboss server info mbean and fallback to the jdk default
if it cannot be found. I don't know if an extension class can get access
to a class fro
dk5, or use a scoped
> xalan.jar to override the jdk version, since xalan.jar contains:
>
> META-INF/services/javax.xml.transform.TransformerFactory file
> containing the class name of its implementation.
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
>
http://jira.jboss.com/jira/browse/JBAS-2789
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Dimitris AndreadisSent: Wednesday, February 22, 2006 10:02
AMTo: jboss-development@lists.sourceforge.netSubject:
RE: [JBoss-dev] JBossCache 1.2.4.SP2 released
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Dimitris Andreadis
> Sent: Wednesday, February 22, 2006 1:09 PM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] Xalan removal saga
>
>
> Removing javax.xml.transform.Tra
> Cc: jboss-development@lists.sourceforge.net; Architect
> Council; QA; Scott M Stark; Ivelin Ivanov
> Subject: Re: Finalizing the Release of JBAS 3.2.8.SP1 &
> 4.0.4.GA - YourHelp is Needed
>
> The JCA, JTA and JMS work is pretty much done.
>
> The outstanding stuff is
There still is the question of if option==true, does it actually work.
That is the integration task issue.
> -Original Message-
> From: Dimitris Andreadis
> Sent: Friday, February 24, 2006 12:40 PM
> To: Scott M Stark; Adrian Brock
> Cc: 'jboss-development@l
installer? If it
is, then we also need an integration test in the jbossas testsuite.
> -Original Message-
> From: Mark Little [mailto:[EMAIL PROTECTED]
> Sent: Saturday, February 25, 2006 5:19 AM
> To: Dimitris Andreadis
> Cc: Scott M Stark; Adrian Brock;
>
[EMAIL PROTECTED]
> Sent: Monday, February 27, 2006 6:08 AM
> To: Scott M Stark
> Cc: Mark Little; Dimitris Andreadis; Adrian Brock;
> jboss-development@lists.sourceforge.net; QA; Ivelin Ivanov
> Subject: Re: RE: Finalizing the Release of JBAS 3.2.8.SP1 &
> 4.0.4.GA - YourHelp
1 - 100 of 4685 matches
Mail list logo
