> It seems "java.naming.factory.initial" in Tomcat 4.0 is set to
> "org.apache.naming.java.javaURLContextFactory" no matter what is the value
> in jndi.properties or
> "-Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFactory".
>
> Does any one know how to handle this?
There's a syst
> Thank you for the insides.
>
> Somehow -Dcatalina.useNaming=false didn't work;"-nonaming" worked.
Just checked the code ...
My mistake, sorry for the trouble. The main class will only look at the
flag, and set the JNDI sys properties and "catalina.useNaming" accordingly.
Remy
___
Scott M Stark wrote:
A 3.0.5 pre-release has been made available for testing. The primary purpse
is to get feedback about the latest class loader changes made to address
the outstanding IllegalAccessErrors. If you have experienced problems
with IllegalAccessErrors or LinkageErrors please try this
Scott M Stark wrote:
There are two layers of integration between web containers
and JSR77 model components I want to implement for 3.2 The
first is the JSR77 WebModule which is handled at the
AbstractWebContainer level. Subclasses of AbstractWebContainer
need to populate the DeploymentInfo.mbeans
Scott M Stark wrote:
That is the issue. I would rather the web container not directly create the JSR77
Servlet model. Instead it should create its own management facade that is used
by the JBoss JSR77 layer to present the Servlet model mbean with the correct
naming structure. So there justs needs
Scott M Stark wrote:
> No, I have no time for this right now. Remy Maucherat will be looking
> at it shortly.
I plan to help out after Tomcat 4.1.12 is out of the door (it should be
tomorrow). Given that 4.1 includes a lot of performance improvements, as
well as the new Jasper 2, it sho
Liam Magee wrote:
> I've fixed the problem I was having earlier, and have a version of
> tomcat-service.jar which integrates JBoss3.0.2 and Tomcat4.1.12. What is
> the process for posting/committing the code for review?
Great job on putting that stuff together so fast.
I think you could submit a
Liam Magee wrote:
> Hi Thomas,
>
> I haven't looked deeply into Tomcat MBean support, this is the next
> natural step for integration b/w JBoss and Tomcat.
I think it would be beneficial to stop using Embedded eventually
(whatever JBoss needs to do should be doable using a host configurator
a
Scott M Stark wrote:
> If you look at the Embedded usage in the JBoss service it is not doing much.
> Being able to run off a sar with the minimum elements from tomcat would be
> good, but I want to keep the ability to run with a pristine tomcat dist.
Using the normal Tomcat startup code directly
julien viet wrote:
I can bend jasper compiler to compile JSP to java classes, I've
already done that.
JSP compilation is now functional again in Tomcat 4.1.x. I recommend you
deploy your production webapps (Nukes, etc) with that and explicit
mappings for the JSPs in web.xml.
You can see all the
Scott M Stark wrote:
We really have not looked into tweaking the jsp compiler layer to see if
the filesystem requirement can be replaced by an input stream or byte[]
view of classes as far as I know. Its something to look into as another
optimization/benefit of embedding the web container into JBos
The Tomcat integration needs work, esp for JB 4, and to take advantage
of the new features introduced in Tomcat 5.
I propose the following changes:
- Eventually remove the shared servlet & JSP API JAR from the shared lib
folder. The idea is that Tomcat 5 can't run (well, it can, but sooner or
Sacha Labourey wrote:
- a new Unix wrapper (we use it for the usual port-80-without-root
problem; it unfortunately wouldn't work with JB, which doesn't have a
well defined init phase)
***
Explain ;)
Well, it's fairly simple.
Basically, it's a native binary, which instantia
Scott M Stark wrote:
I'm putting together a 3.2.3RC1 release to pickup some recent bug fixes.
I'm
working on a fix for [ 832561 ] NoSuchMethodException when HAJNDI joins
cluster
that I want to include. If there are any other must have fixes let me know.
This will include Tomcat 4.1.29, with a few
On 6/22/06, Scott M Stark <[EMAIL PROTECTED]> wrote:
> We should by synching on a release version of jbossweb in the future. It
> makes little sense to me to have jbossweb as a standalone web container
> and not bundle it in the AS. I talked to Mladen about breaking up the
> existing jbossweb proje
On 6/22/06, Scott M Stark <[EMAIL PROTECTED]> wrote:
> Ok, I thought Mladen said the deployer was replicated currently. Yes, we need
> to be able to move at our own pace for the web container and I view that the
> jbossweb project should be the exchange point between tomcat and jbossas.
>
Maybe
- Tomcat 5.0.16 is out, and I've updated the JBoss binaries; it could be
the first stable 5.0.x release, although nothing has been decided yet.
- The session clustering code is now ported to Tomcat 5, but it will
likely need fixes to work.
- Hopefully we'll have a JB 3.2.3 bundle with Tomcat 5 :)
Sacha Labourey wrote:
- The session clustering code is now ported to Tomcat 5, but it will
likely need fixes to work.
Need help? What is the problem?
No problem.
Have you done some testing?
No. It builds :)
--
x
Rémy Maucherat
Senior Developer & Consultant
JBoss Group
Scott M Stark wrote:
Its included in the release in the same manner as 3.2.3RC1, as a sar with
a build file that creates a server/tomcat5 configuration that replaces the
tomcat-4.1.x sar with the tc5 version. The tc5 version cannot be made the
default until it at least passes the
org.jboss.test.we
Hi,
Given HEAD needs to support the new Servlet & JSP specifications, I plan to:
- remove support fot Tomcat 4.1.x
- port all the changes I've made in 3.2 (which integrates TC 5.0.16) to HEAD
Any issues with this ?
--
x
Re'my Maucherat
Senior Developer & Consultant
JBo
Bill Burke wrote:
? worked for me.
Sebastian Hauer wrote:
I was just going to post into the test forum and got a
-
HTTP Status 500 - No Context configured to process this request type
Status report
message No Context configured to process this request
description The server encounter
Hi,
A lot of tweaking have been made in the TC 5 integration with JBoss
3.2.x. All the web console web tier monitoring now work. I think the
only issue remaining is testing clustering. Then the code can be ported
to JBoss 4.0.
After that, new integration features can be added, such as a Tomcat
Going back to the TC 5 integration, I run into a problem while
undeploying the SAR:
22:50:47,367 ERROR [StandardHost] Error creating deployer
java.lang.NullPointerException
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119)
at
org.jboss.mx.loading.UnifiedClassLoade
Hi,
I saw some updates here to the web clustering code from Thomas:
User: tpeuss
Date: 04/01/04 03:54:01
Modified:src/main/org/jboss/web/tomcat/session Tag: Branch_3_2
ClusterManager.java ClusteredSession.java
Log:
Change for bug #863113.
This patch adds a
Scott M Stark wrote:
The class loading failure is due the associated deployment being
destroyed and the class loader removed from the repository. The
class loader reference is invalid, so look into why the class
loader is being used after its deployment is destroyed.
This was working before the JMX
Sacha Labourey wrote:
Hello Rémy,
Would it be possible to switch to TC 5 for JB 3.2.4 (assuming there's
someone to test and bugfix the clustering code) ? I did add the JSR 77
stats, so the web console works and has the same stats as with TC 4.1 now.
It is not my decision but in a recent e-mail (vi
Scott M Stark wrote:
The class loading is the same, the bigger recent change was a refactoring
No, your refactoring didn't break anything, as I did test it earlier.
of the embedded web service into the web container service and a deployer.
I would this is the source of the behavior change. What us
Tom Elrod wrote:
So is this still an issue? If so, how do I reproduce (will look at it
tonight)?
The value of looking into this is that it could possibly be a
regression. Otherwise, the workaround is good enough :)
- Use the TC 5 SAR instead of the TC 4.1 SAR
- In the server.xml of the SAR, rep
Scott M Stark wrote:
The class loading failure is due the associated deployment being
destroyed and the class loader removed from the repository. The
class loader reference is invalid, so look into why the class
loader is being used after its deployment is destroyed.
We need to get the web integrat
Hi,
The necessary web tests now work, and I've cleaned up a bit the
integration. Clustering needs testing.
Tomcat 5.0.17 will be tagged soon, and I'll update the binaries in
thirdparty accordingly.
Once clustering is tested we need to port all this to HEAD (including
Scott's refactoring), and
Scott M Stark wrote:
We can try tc5 as the default in the next 3.2 rc release.
Awesome :)
When is the first beta of 3.2.4 planned, BTW ?
--
x
Rémy Maucherat
Senior Developer & Consultant
JBoss Group (Europe) SàRL
x
---
Tom Elrod wrote:
I am able to reproduce the problem, but after spending a good bit of
time trying to find the bug, I am at a loss. Here is what I have found
so far (Scott maybe you would be able to figure it out based on this
info?).
The LoaderRepository variable, repository, within UnifiedCla
Scott M Stark wrote:
This has been fixed by only unregistering the deployment UCL if the deployment
actually created the UCL as opposed to inherit the UCL from its containing
deployment. The current NPE behavior is an artifact of class loading that
is ocurring now, not any specific behavior change
Bill Burke wrote:
Remember, DR3 freeze is next week. let's shoot for next wednesday. If
you need a few more days, let me know.
Thanks for all the hard work guys!
I found a few recent regressions:
- Some console problems I just fixed (there could be more similar stuff
that I missed, so more te
Hi,
Brian Stansberry submitted some new useful patches for Tomcat, adding
pluggable SSO support, with an implementation of JBoss clustering for
SSO (which would replace the "regular" SSO valve).
The issue it addresses is that when there's a failover, SSO data is lost
and the user would possibl
Scott M Stark wrote:
Yes, In fact I'm looking to add this immedaitely.
Brian's patch seems good, but I didn't fully review it: can we wait
until after 3.2.4, though ?
Some Tomcat changes are needed, and I can't make them appear in a
release within two seconds ;)
--
x
Rém
Scott M Stark wrote:
I want to do another 3.2.4RC2 release before the final so there is time.
Ok. Then we can say that I'll take care of this in Tomcat land soon
enough (since all that is apparently needed is to merge patches, again
thanks to Brian :) ).
--
x
Rémy Mauche
Brian Stansberry wrote:
Hi Remy,
OK, switching a conversation from the TC list to the JBoss list. With TC5's
SingleSignOn now easily extendable, if you'd like I can pretty quickly
rework the TreeCache based implementation I posted on TC Bugzilla and commit
it to JBoss HEAD and Branch_3_2. But, I'
Bela Ban wrote:
Scott M Stark wrote:
Yes, do it please. Is it possible to externalize the choice of the
clustered session manager in tc5/jboss-x.y.z as well? It still
seems to be a hard-coded auto installment whenever the embedded
tc5 layer sees that it is running in a clustered env.
I have alread
Bela Ban wrote:
Yes, like the following snippet shows
org.jboss.web.tomcat.tc5.session.JBossManager
This looks good to me.
--
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x
Scott M Stark wrote:
If you have it ready check it in Bela.
Ok.
BTW, I get two (security related) failures now with the web test case.
I'm checking to see if my last commit caused the problem.
--
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x
Remy Maucherat wrote:
Scott M Stark wrote:
If you have it ready check it in Bela.
Ok.
BTW, I get two (security related) failures now with the web test case.
I'm checking to see if my last commit caused the problem.
I quickly disabled my changes and I still get the two fai
Bela Ban wrote:
Okay, checked in my changes. By default we're using JBossManager as
session manager if a session is marked as distributed.
Todo: TomcatDeployer currently has an ugly if-then-else stmt, which
should be replaced by an init() method, or a regular lifecycle
implemented by any Manager
Scott M Stark wrote:
Ok, I'll look at them.
Forget it: updating the rest of the repository fixed the problems.
(cool: one problem solved)
Remy Maucherat wrote:
Scott M Stark wrote:
If you have it ready check it in Bela.
Ok.
BTW, I get two (security related) failures now with the web
test
On Tue, 9 Nov 2004 14:35:58 -0500 (EST), youngm <[EMAIL PROTECTED]> wrote:
> Is there any kind of timeline of when we can expect some kind of preliminary
> Tomcat 5.5 support in JBoss? Assuming integration is planned will we see it
> in 3.2.x and 4.x or will it only be available in 4.x?
Tomcat
[
http://jira.jboss.com/jira/browse/JBAS-1602?page=comments#action_12316714 ]
Remy Maucherat commented on JBAS-1602:
--
I have applied the patch allowing configuring the servlet options. However, I
don't recommend upgrading the Tomcat binary t
[ http://jira.jboss.com/jira/browse/JBAS-26?page=comments#action_12314922 ]
Remy Maucherat commented on JBAS-26:
The difference in JSP compilation speed should be much bigger in JBoss, since
the classpath is larger than in Tomcat.
To do the
[ http://jira.jboss.com/jira/browse/JBAS-26?page=history ]
Remy Maucherat reassigned JBAS-26:
--
Assign To: Remy Maucherat (was: Scott M Stark)
> Update 4.0.2 to use Tomcat-5.5.x
>
>
>
[ http://jira.jboss.com/jira/browse/JBAS-26?page=history ]
Remy Maucherat resolved JBAS-26:
Resolution: Done
> Update 4.0.2 to use Tomcat-5.5.x
>
>
> Key: JBAS-26
> URL: http://jira
[ http://jira.jboss.com/jira/browse/JBAS-26?page=comments#action_12315017 ]
Remy Maucherat commented on JBAS-26:
I finished the initial porting. I checked a few things before porting,
including testing that WEB-INF/context.xml files were correctly
[ http://jira.jboss.com/jira/browse/JBAS-821?page=history ]
Remy Maucherat updated JBAS-821:
Description:
SourceForge Submitter: ivelin .
The HTTP Response signature should be modified, so that
statistics collection spiders can count JBoss deployments
[ http://jira.jboss.com/jira/browse/JBAS-821?page=history ]
Remy Maucherat resolved JBAS-821:
-
Resolution: Done
Fix Version: JBossAS-4.0.2 Final
Scott implemented this a while ago.
> JBoss HTTP Signat
[ http://jira.jboss.com/jira/browse/JBAS-26?page=history ]
Remy Maucherat updated JBAS-26:
---
Environment:
Fix Version: JBossAS-4.0.2RC1
(was: JBossAS-4.0.2 Final)
> Update 4.0.2 to use Tomcat-5.
Reporter: Remy Maucherat
Assigned to: Ben Wang
Fix For: JBossAS-4.0.2RC1
Sessions are not correctly stored inside JBossCache, which can in some cases
cause a single web session to be shared across all the web applications
deployed on the server. This is very visible when using emptySessionPath
-4.0.2RC1
Reporter: Remy Maucherat
Assigned to: Remy Maucherat
Priority: Blocker
Fix For: JBossAS-4.0.2RC1
Session tracking is incorrect when using emptySessionPath, which is a setting
needed for JBoss portal. This should be fixed by integrating a new interim
Tomcat binary
Versions: JBossAS-4.0.2RC1
Reporter: Remy Maucherat
Assigned to: Remy Maucherat
Fix For: JBossAS-4.0.2RC1
With the latest changes, it turns out emptySessionPath="true", which is needed
for JBoss Portal compatibility, is a good default setting, and provides fully
func
Tomcat 5.5.8 integration
Key: JBAS-1401
URL: http://jira.jboss.com/jira/browse/JBAS-1401
Project: JBoss Application Server
Type: Feature Request
Components: Web (Tomcat) service
Versions: JBossAS-4.0.2 Final
Reporter: Remy
[ http://jira.jboss.com/jira/browse/JBAS-1399?page=history ]
Remy Maucherat resolved JBAS-1399:
--
Resolution: Done
> emptySessionPath setting breaks session tracking
>
>
> Ke
[ http://jira.jboss.com/jira/browse/JBAS-1401?page=history ]
Remy Maucherat reassigned JBAS-1401:
Assign To: Remy Maucherat (was: Scott M Stark)
> Tomcat 5.5.8 integration
>
>
> Key: JBAS-1401
>
[ http://jira.jboss.com/jira/browse/JBAS-1400?page=history ]
Remy Maucherat resolved JBAS-1400:
--
Resolution: Done
> emptySessionPath="true" as the default setting
> --
>
>
[
http://jira.jboss.com/jira/browse/JBAS-1381?page=comments#action_12315354 ]
Remy Maucherat commented on JBAS-1381:
--
Porting the fix for this issue to 4.0.2 will not be needed, as long as the
JBoss manager does not intend to be used as a
[
http://jira.jboss.com/jira/browse/JBAS-1008?page=comments#action_12315355 ]
Remy Maucherat commented on JBAS-1008:
--
If the WAR is properly packaged with the beans inside an EAR (or a SAR if you
don't care about using JBoss archive format),
[ http://jira.jboss.com/jira/browse/JBAS-956?page=history ]
Remy Maucherat resolved JBAS-956:
-
Resolution: Won't Fix
It will never be fixed upstream and/or integrated in a Tomcat 4.1 release, so
this will not be fixed.
> Problem compi
[ http://jira.jboss.com/jira/browse/JBWEB-11?page=comments#action_12315357
]
Remy Maucherat commented on JBWEB-11:
-
There is a bugzilla entry on this issue that I resolved as INVALID:
http://issues.apache.org/bugzilla/show_bug.cgi?id=31567
The
[ http://jira.jboss.com/jira/browse/JBAS-1329?page=history ]
Remy Maucherat resolved JBAS-1329:
--
Resolution: Rejected
If this happens also in Tomcat standalone, please report it against Tomcat.
If it does happen only in JBoss, you may reopen the
[
http://jira.jboss.com/jira/browse/JBAS-1399?page=comments#action_12315463 ]
Remy Maucherat commented on JBAS-1399:
--
It doesn't hurt to implement it, but it was actually useless with the Tomcat
5.5.8-dev version I integrated.
> emptySes
[ http://jira.jboss.com/jira/browse/JBAS-1401?page=history ]
Remy Maucherat resolved JBAS-1401:
--
Resolution: Done
Fix Version: JBossAS-4.0.2RC1
(was: JBossAS-4.0.2 Final)
> Tomcat 5.5.8 integrat
[ http://jira.jboss.com/jira/browse/JBAS-1401?page=history ]
Remy Maucherat closed JBAS-1401:
> Tomcat 5.5.8 integration
>
>
> Key: JBAS-1401
> URL: http://jira.jboss.com/jira/browse/JBAS-1401
[ http://jira.jboss.com/jira/browse/JBAS-901?page=comments#action_12315758
]
Remy Maucherat commented on JBAS-901:
-
AFAIK, leaving wars packed only works when the Tomcat classloader is used
(useJBossWebLoader set to false).
> setting unpackW
[
http://jira.jboss.com/jira/browse/JBAS-1516?page=comments#action_12315773 ]
Remy Maucherat commented on JBAS-1516:
--
This is now fixed in Tomcat upstream. Thanks for the report.
> Tomcat5: StandardContext getConfigBase tries to creat
[ http://jira.jboss.com/jira/browse/JBAS-1516?page=history ]
Remy Maucherat resolved JBAS-1516:
--
Resolution: Done
> Tomcat5: StandardContext getConfigBase tries to create a direct
[ http://jira.jboss.com/jira/browse/JBAS-1206?page=history ]
Remy Maucherat resolved JBAS-1206:
--
Resolution: Rejected
As with standalone Tomcat, please refer to the URL encoding related attributes
of the connector in Tomcat's document
[ http://jira.jboss.com/jira/browse/JBAS-1401?page=history ]
Remy Maucherat reopened JBAS-1401:
--
> Tomcat 5.5.8 integration
>
>
> Key: JBAS-1401
> URL: http://jira.jboss.com/jira/b
[ http://jira.jboss.com/jira/browse/JBAS-1401?page=history ]
Remy Maucherat updated JBAS-1401:
-
Summary: Tomcat 5.5.9 integration (was: Tomcat 5.5.8 integration)
Description: JBoss 4.0.2 should integrate Tomcat 5.5.9 for support of JBoss
Portal
[ http://jira.jboss.com/jira/browse/JBAS-1401?page=history ]
Remy Maucherat resolved JBAS-1401:
--
Resolution: Done
> Tomcat 5.5.9 integration
>
>
> Key: JBAS-1401
> URL: http://jira.jboss.
[ http://jira.jboss.com/jira/browse/JBAS-1401?page=history ]
Remy Maucherat closed JBAS-1401:
> Tomcat 5.5.9 integration
>
>
> Key: JBAS-1401
> URL: http://jira.jboss.com/jira/browse/JBAS-1401
[ http://jira.jboss.com/jira/browse/JBWEB-14?page=history ]
Remy Maucherat resolved JBWEB-14:
-
Resolution: Done
Tomcat 5.5.9 fixes this. Tomcat specific issues should be reported to Tomcat.
> jsp:include fails when url contains parameter w
[ http://jira.jboss.com/jira/browse/JBWEB-11?page=comments#action_12314771
]
Remy Maucherat commented on JBWEB-11:
-
I know about this issue: it is caused by improper implementation of
expectations by the .NET client.
Essentially, the client sends
78 matches
Mail list logo
