Update of /cvsroot/jboss/jboss/src/resources/org/jboss/metadata
In directory usw-pr-cvs1:/tmp/cvs-serv3831
Modified Files:
jboss.dtd
Log Message:
Add the security-proxy element and update the role-mapping-manager,
authentication-module content model
Update of /cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins
In directory usw-pr-cvs1:/tmp/cvs-serv9993/security/plugins
Modified Files:
AbstractServerLoginModule.java
Added Files:
ObjectCallback.java
Log Message:
Added an LdapLoginModule and test cases.
Generalized
Update of /cvsroot/jboss/jbosssx/src/main/org/jboss/security
In directory usw-pr-cvs1:/tmp/cvs-serv9993/security
Modified Files:
NestableGroup.java
Log Message:
Added an LdapLoginModule and test cases.
Generalized the AbstractServerLoginModule to be more reusable and updated
login
The current cvs dist contains two older versions of the jaxp classes
and sun xml parser as the lib/ext/xml.jar and lib/parser.jar files. These
need to be removed and updated to the jaxp1.1 version which adds
support for pluggable transformations.
The current org.jbossmq.xml.XElementProducer
I would rather not have knowledge of 3rd party app server deployment
descriptors in the core JBoss code as it would only complicate understanding
of how the jboss.xml and standardjboss.xml descriptor are used. Its a fine
idea but it could be implemented via a utility that transformed the app
You can do this with via the ExternalContext mbean. See the howto for
an example of binding a FS context into JNDI.
- Original Message -
From: Rob Castaneda
To: [EMAIL PROTECTED]
Sent: Monday, April 02, 2001 8:32 PM
Subject: RE: [JBoss-dev] File input for a Bean
Use JNDI - download
-
Christer Grimsth
Consultant
TietoEnator Consulting AS, Energy Components.
http://www.energy-components.com
FROM: Scott M Stark
DATE: 04/02/2001 21:02:43
SUBJECT: [JBoss-dev] Log4jService rolled into 2.3 core
I integrated Fulco Muriglio's log4j based mbean into the org.jboss.logging
package a
I will be. The jbosssx.jar that is included in the 2.2 branch needs to be updated
so I'm working on that.
- Original Message -
From: "marc fleury" [EMAIL PROTECTED]
To: "Bordet, Simone" [EMAIL PROTECTED]; "JBoss Development Mailing List
(E-mail)" [EMAIL PROTECTED]
Sent: Wednesday, April
The sourceforge cvs online viewer was showing the available tags previously, at
least I thought I had seen them. Now the tags popup list is showing:
newsite
MAIN
HEAD
avendor
arelease
Any idea why this changed and how to restore the valid tags?
I added a JBoss_2_2_0_Final to the jbosssx module codebase that went into
the JBossSX jars(jbosss-client.jar, jboss-jaas.jar, jbosssx.jar) included with
the JBoss_2_2_0_Final release. This allows the source for these to be obtained
and patched if necessary.
I think we need to do the same for the
The ApplicationMetaData importJbossXml always prefixes
the value of res-jndi-name elements from jboss.xml with java:/ which
makes it impossible to access resources that are not under the java:
context. One example are the JMS queue and topic factories which
are bound under the top level names
Ok, the issue is that Jetty is not using a simple MBean, its using a ModelMBean
which is a more dynamic entity that does not expose its methods statically.
Therefore the MBeanServer has to pass the method invocation onto the bean
to see if its implemented, and in this case it is not.
The stack
They can't create a wrapper because mbeans are being created as a byproduct
of interaction with the Jetty JMX interface. This is a generic issue with integrating
third party services that happen to be mbeans which may be using the JMX bus
for whatever purpose. Its trivial to add a filter by
RequestID 415472 has been created for this issue on sourceforge.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Ok, a problem mentioned on the user list turns out to be a bug in the 2.2
release of the JBossSX code. This was not seen because the login module
used in the howto was not being convered in the unit tests(my fault).
So, what is the procedure for creating a patch and new release on the
2.2
The code that needs to be patched is actually in the jbosssx cvs module. I did
add a JBoss_2_2_0_Final to the code in this module at the time of the
2.2 release, but I did not make a branch.
Would this work:
cvs rtag -b -r JBoss_2_2_0_Final Branch_2_2 jbosssx
co -rBranch_2_2 jbosssx
-
I integrated the JBossSX patched jars and tagged everything under
jboss with Rel_2_2_1 for now. If you have something that should
be integrated into the 2.2.1 release I believe the correct proceedure
is:
1. Check out the 2.2.1 version:
cvs co -r Rel_2_2_1 jboss
2. Make your changes
...
3.
1. Check out the 2.2.1 version:
cvs co -r Rel_2_2_1 jboss
I think the best is to always checkout the most recent code on the branch,
so
cvs co -rBranch_2_2 jboss
How does the Branch_2_2 tag always refer to the latest code on the branch?
4. Move the Rel_2_2_1 tag from within the
Nobody has yet given me a good reason why we should
force a DynamicMBean to decide who manages it's
lifecycle, at compile time (what you are suggesting)
or at deployment time (stick it in a config file)
instead of at runtime (which I am suggesting).
There has to be some configurable
I tried filtering services to those than implemented the org.jboss.util.Service
interface by implementing a solution that performs that same test as the
MBeanServer.isInstanceOf(String) method, but uses the thread context
class loader to obtain the bean class. This works except for this mbean:
I would agree. It is a cleaner naming convention in my mind.
Bordet, Simone wrote:
My idea of using the Rel_x_y_z tags was related to merging only, so those
tags are "internal" and go their way, separated from the JBoss_x_y_z tags
that instead represent a "public" release.
So,
We get bored of producing different types of train, some for France and some for
England, and
decide that it would be easier to manufacture one type of Train which figured out
which Country
it was in and adapted it's electric motor automagically to the available
power-supply (perhaps
it
This post on the JINI list refers to an article that to me is the heart of the whole
"Nested JMX Service Groups" thread disagreements.
- Original Message -
From: "Eric" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 12, 2001 6:44 PM
Subject: Semantic Web
From
After much talking by me and some listening, here is the solution were going
with that I believe addresses all issues and requires no changes to existing
services and configurations:
1. The org.jboss.util.ServiceControl mbean service no longer listens for
mbean registration events as the means
The summary field of the tracker forms is limited to 40 chars and
I'm being limited by this. Can this be expanded or is it fixed by
sourceforge?
___
Jboss-development mailing list
[EMAIL PROTECTED]
I'm planning on a 2.2.1 bug fix release for APR 18 now. It seems like
only Dan and myself have fixes to incorporate. If you have a fix you
want in this release let me know.
___
Jboss-development mailing list
[EMAIL PROTECTED]
I think it is a bug for 2.2 as I cannot run the current ENC naming tests that
need to access the JMS queue/topic factories because of this issue. I'll
update the change note to include more details.
- Original Message -
From: "Toby Allsopp" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent:
I don't have a strong opinion on its inclusion so if in general this is going to
cause more problems then it solves it can be left out of the 2.2.1 release.
An ApplicationMetaData level compatability flag could be added to indicate
whether the java:/ prefix should be assumed and this could be
A change will be required if you have a res-jndi-name element in your jboss.xml
descriptor that is relying on the implied java:/ prefix being added. For example if
your using:
resource-managers
resource-manager res-class=""
res-nameDefaultDS/res-name
That is correct. There will be no code changes required. Only certain undocumented
usage of the jboss.xml descriptor res-jndi-name element will require changes to the
res-jndi-name element.
- Original Message -
From: "danch" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April
There seems to be a bit of confusion as to exactly what the ApplicationMetaData
change that I committed is and what its impact will be. I'll describe the current
problem and then suggest an integration of the patch into the 2.2.1 release that
won't break any code or jboss.xml descriptors but will
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't use CLASSPATH in run.bat/run.sh
Initial Comment:
Removed the use of the system CLASSPATH variable as
this results in too many conflicts in general. Changed
CLASSPATH to JBOSS
I tried cleaning up some of the tests that were not implemented as valid JUnit test
cases but there are still 5 unit tests that have errors/failures that need to be fixed.
They are:
testsuite name="org.jboss.test.cts.test.AllJUnitTests" tests="19" failures="4"
errors="0" time="11.547 sec"
As long as you don't have a Context.PROVIDER_URL set in the env
passed to InitialContext or jndi.properties the Context returned is the
RMI implementation object and calls on it should not involve RMI
invocations.
- Original Message -
From: Bill Burke
To: Jboss-Development@Lists.
jboss/src/main/test/* is for unit tests of internal server components. The
JBossTest suite is for testing the behavior of the server via its public interfaces.
- Original Message -
From: "Jason Dillon" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 18, 2001 6:11 PM
A new 2.2.1 release is available from the jboss.org page at sourceforge along
with a JBoss2.2.1/Tomcat3.2.1 bundle. See http://sourceforge.net/projects/jboss/
An new JBoss2.2.1/Jetty bundle will be released later today.
See the Change Notes with Group=v2.2.1 for the changes relative to the
Try it now.
- Original Message -
From: "Juha-P Lindfors" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, April 22, 2001 12:41 PM
Subject: [JBoss-dev] NamingAlias: won't compile
Scott,
the current CVS checkout won't compile because ServiceMBean interface is
missing
, April 23, 2001 12:16 PM
Subject: Re: [JBoss-dev] ExternalContext Context.close()
Aren't clients expected to close contexts? Or are they only expected to
close InitialContexts?
--jason
On Thu, 19 Apr 2001, Scott M Stark wrote:
The Context mapped via ExternalContext is only created
You don't have to put the EJB classes into the WEB-INF/classes directory for
servlets to be able access them. They have to be there for jsp pages that access
the beans because the jasper compiler was is only given the WEB-INF/classes
directory.
Do you have a non-jsp example that requires
The main branch has been updated to use the org.apache.log4j framework
as the default logging implementation. One question is why not adopt the
log4j framework as the JBoss logging interface as well? I don't see any downside
to this and there are many benefits. Are there any objections to
Its only used when someone configures it for their security domain. By
default it is not configured for use.
- Original Message -
From: Jay Walters [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 25, 2001 9:17 AM
Subject: RE: [JBoss-dev] jdbc2_0-stdext.jar in /lib
Something is amiss with your server as these errors are all related to
the JMX connector not being bound in JNDI and I don't see this
problem. When I run the tests I am seeing the same errors as before.
- Original Message -
From: Chris Kimpton [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
not from lib/ext? The reason I am asking is
that it is the only bit of the j2ee replacement jar which we've built which
can't go in lib/ext right now.
Cheers
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 25, 2001 12:40 PM
To: [EMAIL
against the build.
- Original Message -
From: Chris Kimpton [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 25, 2001 10:20 AM
Subject: Re: [JBoss-dev] jboss daily test results
Hi,
From: Scott M Stark [EMAIL PROTECTED]
Something is amiss with your server
I'll look into it. The jnp url context factory is who is responsible for
creating a context capable of resolving the remote name. I don't
believe the problem is with the current checkRef() logic.
- Original Message -
From: Anatoly Akkerman [EMAIL PROTECTED]
To: JBoss-Dev [EMAIL
The timing increase seems to be do to the latest version of Hypersonic. I see
a long pause(20-30) secs on the console after these msgs:
[Hypersonic] Starting
Server 1.4 is running
Press [Ctrl]+[C] to abort
...
JBoss 2.3 BETA Started in 0m:37s
This used to start in under 10 secs on my box so
Right, the name should be the full jnp url not just the local jndi name.
- Original Message -
From: Alf Werder [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 26, 2001 8:50 AM
Subject: Re: [JBoss-dev] Bug in jnp (handling references to remote JNDI servers)
The problem
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 26, 2001 12:10 PM
Subject: Re: [JBoss-dev] Remote Proxies do not know the server they came from
I spent some time (long ago...) fixing this very problem, but I have not
really had
This is not a generic solution. It's simply a work around for a special case.
Besides it
only allows a once off configuration, what if I later want to add another
configuration
? It might be sufficient for this one simple case, but not much more.
The jboss.jcml file is a read once
The tomcat-test.ear is about the extent of the servlet integration testing.
and this is basically a pass/fail manual inspection test. I am creating
a servlet integration unit test in the jbosstest module for automated
testing of servlet container integration. The first cut should be ready
this
We use a double indirection layer to resolve the JNDI name for an ejb-jar/resource-ref
element and I don't see why this can't be handled by a single layer. For example, given
a javax.sql.DataSource reference in an ejb-jar like
ejb-jar
enterprise-beans
session
The patchdir thing is something that I added so that one could create a patch
of a given binary release. It was how I tested the initial JBossSX stuff.
- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 07, 2001 7:33 PM
Subject: RE:
Logging in general is not sufficient in JBoss. I believe we need to move
to using log4j with some additional priorities so that one can truly
understand what is going on in arbitrary detail at the flick of a JMX
switch.
- Original Message -
From: marc fleury [EMAIL PROTECTED]
To:
Everyone uses it. This is simply a utility class that installs the container
interceptors as defined by the configuration.
Finally why the static call to stacks initialization
ContainerInterceptors.addInterceptors(container, transType,
metricsEnabled,
You have to setup cvs over ssh access to not ask for a password by
uploading your private key as described at:
Am I forced to enter my password for every cvs command?
http://sourceforge.net/docman/display_doc.php?docid=765group_id=1#ssh-key
- Original Message -
From: Julian Gosnell
The new details format page looks great.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 08, 2001 6:46 PM
Subject: [JBoss-dev] jboss daily test results
=
==THIS IS AN
- Original Message -
From: marc fleury [EMAIL PROTECTED]
the security initialization from jboss.properties, we need to move that to a
proper JMX initialization. Move the thread local security stuff, is it
there because there is no other way? is there a reason, or can we safely
Where are you seeing the use of the btye[]/InputStream.available construct
as in:
byte[] buffer = new byte[input.available()];
input.read(buffer);
I searched the entire jboss org/jboss codebase and I cannot find any existing
uses of this construct.
- Original Message -
From:
Ok, right. I don't try to access the EnterpriseContext associated with the
MethodInvocation and if I did, it would not have been set yet.
- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 09, 2001 3:13 PM
Subject: RE: [JBoss-dev]
to bother the list with clean-ups
marc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Wednesday, May 09, 2001 6:45 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] METHOD-INVOCATION
|
|
|Ok, right. I don't try
Actually I have the security integration working and its pretty simple.
I have rewritten the tomcat3.2.1 mbean using it and it is working so
I'll check in the updated AbstractWebContainer tonight.
- Original Message -
From: Julian Gosnell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc:
don't want to remove that.
marc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Tuesday, May 08, 2001 3:26 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] LogInterceptor
|
|
|Logging in general is not sufficient
I think it would be nicer if performUndeploy() passed
me not the warUrl (since then I have to maintain a
table of warUrl to webApp, or look it up in yours) but
either the WebApplication object, or it's appData
(Jetty's WebApplicationContext).
Ok, how about the warUrl and WebApplication
Yes, I need to update the jbosssx.jar. It will be in soon.
- Original Message -
From: Chris Kimpton [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 10, 2001 12:53 PM
Subject: [JBoss-dev] BUILD PROBLEM - missing class
org.jboss.security.plugins.NullSecurityManager
Hi,
Let me know what is required. Any management integration interface should be
exposed through the new AbstractWebContainer class so that every web container
integrater knows what the requirements are. As much as possible should be
handled automatically by the AbstractWebContainer itself.
-
I'm writing a new howto on integrating servlet containers
into JBoss using the new AbstractWebContainer class. It
provides support for integrating web-app.xml items into
the JNDI namespace as well as hooking into the JBossSX
authentication and authorization layer. The doc will be
out on the web
What is out of synch is the jboss-client.jar you are using.
The JBoss-2.3 org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy
has a serialVersionUID = 432426690456622923L:
client 571serialver -classpath jboss-client.jar
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy
This has been done.
- Original Message -
From: Oleg Nitz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 21, 2001 3:47 AM
Subject: [JBoss-dev] jbossmq.xml
Please, somebody who has CVS rw access, copy jbossmq.xml from jbossmq
module to jboss module (I am behind firewall
I agree that the current build structure is poor and what your proposing has
merit, but it requires that modules main branch be in step with the JBoss server
main branch which may not be workable as module owners come and go and
work progresses at an independent rate.
There should be a stronger
The AbstractWebContainer is already in the main branch. I'll look
at adding the mgmt. I'm not sure that there is sufficient integration
with the web containers to add/remove an individual Servlet, or
that they even support such an API. Is this going to be a JMX
requirement?
What is the
Ok, I'll change it.
- Original Message -
From: Mike Swainston-Rainford [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 22, 2001 3:38 PM
Subject: Re: [JBoss-dev] Looking to do 2.2.2 release
Hi
I'm working on the Together 5.0 JBoss deployer . I don't have CVS write
: testSecureServlet took 0 sec
[junit] Testcase: testSnoopJSP took 0 sec
BUILD SUCCESSFUL
I'll try it against the jetty contrib code.
- Original Message -
From: Julian Gosnell [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2001 3:22 PM
] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217)
[Default]
[Default] at java.lang.Thread.run(Thread.java:484)
[Default]
[Jetty]
javax.servlet.ServletException: Failed to init EJBOnStartupServlet
- Original Message -
From: Julian Gosnell [EMAIL PROTECTED]
To: Scott M
]
To: Scott M Stark [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2001 3:22 PM
Subject: [JBoss-dev] JBoss-Jetty latest AbstractWebContainer/WebDescriptorParser
Scott,
I've moved jboss-jetty over onto your WebDescriptorParser stuff.
if you have the contrib module chcked
Use the JBoss_2_2_1 tag if you want stable 2.2 code. The Branch_2_2 is in
flux in preparation for the upcoming 2.2.2 release.
- Original Message -
From: Lars Hofhansl [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 23, 2001 6:20 PM
Subject: [JBoss-dev] Branch_2_2 build
No, I have not created the JBoss_2_2_2 tag because I'm waiting for a jaws update.
I will merge the change.
- Original Message -
From: Juha Lindfors [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 30, 2001 2:58 PM
Subject: Re: [JBoss-dev] Please help me understand CVS tags
Your compiling with JDK1.4 to see this as Throwable did not have a getCause method
until 1.4. I would think that the org.jboss.ejb.DeploymentException be dropped in
favor of org.jboss.deployment.DeploymentException.
- Original Message -
From: Darius Davidavicius [EMAIL PROTECTED]
To:
That would be one way and IIS Apache have WEBDAV modules and tomcat includes
a WEBDAV servlet. We would need to add a webdav stream protocol handler
that mapped the directory content into an array of URLs for the jars. The same
approach could be used for any service capable of providing a
This is due to today's changes in the JMSContainerInvoker.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 31, 2001 6:32 PM
Subject: [JBoss-dev] jboss daily build failed - in cvs module: jboss
A new 2.2.2 maintenance release is available at sourceforge from the Files section
of the jboss.org project: http://sourceforge.net/project/showfiles.php?group_id=22866
along with the change notes.
It includes a few bug fixes and a few enhancements including a new AbstractWebContainer
support
Ok. What you have is fine.
- Original Message -
From: Chris Kimpton [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, June 01, 2001 12:53 AM
Subject: Re: [JBoss-dev] jboss daily build failed - in cvs module: jbosssx
Hi,
The problem is that I have no dependency checking between
I have rerun the jbosstest suite and I am also seeing errors on tests that worked a
couple of days ago. Most of the new errors are complaints about not being able to
load a ResultSet column due to an EOFException like that shown below. The corresponding
server log exception follows and shows the
Start by tracking down the current tracking down the current cmp errors
seen in the bank module of the jbosstest suite. There's nothing like
jumping into the deep end off of the high dive from the start.
- Original Message -
From: K S Sreeram [EMAIL PROTECTED]
To: Juha Lindfors [EMAIL
But your change works fine in the 2.2.2 codebase as I ran the same testsuite
against it before making the release and I reran it today and it does not show
the same errors. Is there a difference in the code comitted to the 2.2.2 branch
versus main?
The tests typically run against the DefaultDS
I've looked into this bug using a simple RMI client/server testcase that
simulates the behavior in JBoss in that the remote objects it exports
are loaded by an application class loader. The fact that the annotated
codebase of the class is a file url on the server is due to the fact that
this is
This really should be fixed by having a new URLClassLoader subclass that
returns the java.rmi.server.codebase so that code can be properly downloaded
to the clients while still loading classes from the local urls. This fixes
the current
dynamic class loading problem. I have a solution based on
This is fixed in main. See the ContainerFactory, WebService, WebServer
and WebClassLoader for the changes.
- Original Message -
From: Joseph Dane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 11:59 AM
Subject: Re: [JBoss-dev] MarshalledObject + URLClassLoader =
There is either a bad import or a missing class in
Scheduler.java:
compile: [javac] Compiling 1
source file to
D:\usr\local\src\cvsroot\jBoss\jboss\build\classes [javac]
D:\usr\local\src\cvsroot\jBoss\jboss\src\main\org\jboss\util\Scheduler.java:35:
Class management.J2EEApplication not
Periodically on redeploy of an ejb jar via the JMX connector I am seeing the
following exception related to creation of the org.jboss.mgt.ContainerMgt bean
in the ContainerFactory.registerContainer method. This is an exception I have
not seen before.
private void registerContainer( Container
Each JNDI enterprise naming context(ENC) has to be unique for a J2EE
component(ejb, war). We establish the uniqueness of the ENC context
by creating a new ClassLoader for each component. This works fine for
EJBs, but a few issues have show up for web components for a number
of reasons. Example
some inside to the exception.
Andy
- Original Message -
From: Scott M Stark [EMAIL PROTECTED]
To: JBoss Dev [EMAIL PROTECTED]
Sent: Sunday, June 10, 2001 12:02 PM
Subject: [JBoss-dev] org.jboss.mgt.ContainerMgt RuntimeException
Periodically on redeploy of an ejb jar via
to the specification).
This swizzling is done in the BaseLocalContainerInvoker.
Is this question just from code review, or did you notice incorrect
runtime behavior?
-Dan
On 10 Jun 01, at 16:23, Scott M Stark wrote:
I can't seem to find how the current interceptor architecture
I created a RabbitHole branch off of the current main line for prototyping
the 3.0 generation of JBoss. You can access the branch via the command
line version of cvs using:
cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co -r
RabbitHole jboss
___
It should be added to the 2.2.x branch as well. Let Marc review the
current patch and then commit once its blessed.
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 11, 2001 2:13 PM
Subject: RE: [JBoss-dev] Screwed up: commited into
Its something on my todo list. I'm thinking of adding the DTD validation
to the bean verifier step of deployment.
- Original Message -
From: Darius Davidavicius [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 12, 2001 8:46 AM
Subject: [JBoss-dev] ejb-jar.xml DTD checking
to work on the main trunk and since most
development effort is going into 3.0 let's just freeze 2.4, branch the 2.4,
release 2.4 BETA and fix 2.4 issues in the branch. Keep main
development in the trunk.
-- Juha
On Mon, 11 Jun 2001, Scott M Stark wrote:
I created a RabbitHole branch
understand that we all will be working on that branch... I am ok with it
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Tuesday, June 12, 2001 1:10 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] RabbitHole branch
Agreed. Let's make it so. How about trying for a code freeze as of next
Monday (June 18 2001).
- Original Message -
From: Ole Husgaard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 12, 2001 1:31 PM
Subject: Re: [JBoss-dev] RabbitHole branch created
Hi,
I agree, and
Fixed.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 12, 2001 6:35 PM
Subject: [JBoss-dev] jboss daily build failed - in cvs module: jbosssx
=
==THIS IS AN AUTOMATED EMAIL
As of today's latest cvs code, on redeploy of a ejb-jar I am seeing
a new InstanceAlreadyExistsException exception when a
org.jboss.mgt.ContainerMgt is created in the ContainerFactory
registerContainer method. Here is the point at which the module
is stopped and reployed and the exception that
1 - 100 of 4240 matches
Mail list logo
