Re: Question Regarding McastServiceImpl#setupSocket
Hi ChrisIn macOS test server, when configuring the mcastBindAddress as
192.168.1.139 and address as 228.0.0.4 , the code does not use mcastBindAddress
, instead it uses multicast address for socket binding and throws exception
when sending the datagram packet. Here is the exception:
Exception in thread "main" org.apache.catalina.tribes.ChannelException:
java.io.IOException: Can't assign requested address (sendto failed); No faulty
members identified.
at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:207)
at
org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:111)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:165)
at
org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.start(MessageDispatchInterceptor.java:228)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:165)
at
org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:483)
at test.MemberShipTest.main(MemberShipTest.java:44)
Caused by: java.io.IOException: Can't assign requested address (sendto failed)
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:693)
at
org.apache.catalina.tribes.membership.McastServiceImpl.send(McastServiceImpl.java:505)
at
org.apache.catalina.tribes.membership.McastServiceImpl.send(McastServiceImpl.java:482)
at
org.apache.catalina.tribes.membership.McastServiceImpl.start(McastServiceImpl.java:268)
at
org.apache.catalina.tribes.membership.McastService.start(McastService.java:289)
at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:196)
... 6 more
When I changed the address to mcastBindAddress while creating the socket, no
more exception occurred.Regards.Gurkan
On Thursday, May 30, 2019, 5:56:46 PM GMT+3, Christopher Schultz
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gurkan,
On 5/29/19 02:28, Gurkan Erdogdu wrote:
> Hi In an McastServiceImpl#setupSocket method, if the user
> configures the mcastBindAddress, it will use the socket to bind to
> this address. But, in the code below, it uses the "address" field
> while creating the socket. Is this correct ?
>
> if (mcastBindAddress != null) { try {
> log.info(sm.getString("mcastServiceImpl.bind", address,
> Integer.toString(port))); socket = new MulticastSocket(new
> InetSocketAddress(address,port)); } catch (BindException e) {
That definitely does look weird.
The constructor for McastServiceImpl is even more strange:
/**
* @param bind - the bind address (not sure this is used yet)
* @param mcastAddress - the mcast address
*/
public McastServiceImpl([...],
InetAddress bind,
InetAddress mcastAddress,
[...])
throws IOException {
[...]
this.address = mcastAddress;
this.mcastBindAddress = bind;
[...]
}
There are two items, here:
1. An address to bind to (locally)
2. A multicast target address
The constructor takes these two and calls them:
1. bind
2. mcastAddress
But the class members are called:
1. mcastBindAddress
2. address
The mcastBindAddress appears to be ignored in all but one place, where
the socket's interface is changed to it at McastServiceImpl.java:223:
220 if (mcastBindAddress != null) {
221 if(log.isInfoEnabled())
222 log.info(sm.getString("mcastServiceImpl.setInterface",
mcastBindAddress));
223 socket.setInterface(mcastBindAddress);
224 } //end if
I don't know enough about multicast to know what is supposed to be
happening, here. AFAIK, mcast is a broadcast mechanism and so there is
no difference between the "target" address and the "bind" address: you
just throw packets at the interface:port and that's that.
The code could probably use some clean-up, or at least some better
in-code documentation by someone who has a good understanding of the
whole situation.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzv7ysACgkQHPApP6U8
pFjuNg/8DkSdnsKkoTmGS1N37IXVcdj5cyHlmPC+BdP3NWE4oky0j5uFrGUqcaRG
UJLsPMvtZwgSaQ/wxgin4maluAmK77Agt76r6tXJNbbpdglXVyz7ONWO8a5xmk9R
ltqLWnHVw4a/HB5vatxFgqWWc6L1qWnocJL7/sWUn1M9y9Ee43/+h5OYnaBn9bCM
R1jqVhZAodC2k1eD3HXedCMaVIA4k2fZF+TteOHNu2rDr01mJVZzPjNJ/zy4sNg7
L0P0uuqCp3ylh563c3t+slL/9XFoVDNytD46qJlmDDcOYczNjf5An6dyWBJEX348
d0FdWOw5h45lJKhMd1L9WNLymxj3gQ9a3okfhiEqyunsZA4SbMNCPgy4an8tzBsd
HsX1dNgD6P8aoy2umG6SvqgAoPb0mZxlVVT1NdbXN0uybdv/mUJgjDHNsbaCYOxG
UNBfT/p5VQxURhRuNqHsFYvHtA6pxt8mZBbwsHC6b/uOYgPXPrLbM4oQztF2YEzI
RDOr2kmA+JbEj5qKOeQa3BVGT5bUeLRWH+fDFiXq6ubdBdvHAifPJyGdYgAFLvZq
jm85WJJeNvluwB602JUJ/FFxCYe6sKL7jaqfZJClqZrscUDxve0Fckh9xLr
Question Regarding McastServiceImpl#setupSocket
HiIn an McastServiceImpl#setupSocket method, if the user configures the
mcastBindAddress, it will use the socket to bind to this address. But, in the
code below, it uses the "address" field while creating the socket. Is this
correct ?
if (mcastBindAddress != null) {
try {
log.info(sm.getString("mcastServiceImpl.bind", address,
Integer.toString(port)));
socket = new MulticastSocket(new
InetSocketAddress(address,port));
} catch (BindException e) {
Regards.Gurkan
Re: ThreadLocal Clear References Problem
So, you are stopping a second application from the code shown in the bug? Yes. Can you post a working example? I will try to attach a simple JSF application. Thanks; --Gurkan - Original Message From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Developers List dev@tomcat.apache.org Sent: Thu, January 6, 2011 7:32:10 PM Subject: Re: ThreadLocal Clear References Problem Gurkan, On 1/6/2011 7:08 AM, Gurkan Erdogdu wrote: Could you see the problem in https://issues.apache.org/jira/browse/MYFACES-3006? So, you are stopping a second application from the code shown in the bug? Can you post a working example? -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
ThreadLocal Clear References Problem
Hello folks Could you see the problem in https://issues.apache.org/jira/browse/MYFACES-3006? Thanks for your comments! --Gurkan - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1029527 [1/2] - in /tomcat/trunk/java/org/apache/catalina: ./ connector/ core/ ha/deploy/ loader/ manager/ mbeans/ realm/ session/ startup/ util/
Thanks Mark! Works as expected now. --Gurkan - Original Message From: Mark Thomas ma...@apache.org To: Tomcat Developers List dev@tomcat.apache.org Sent: Mon, November 1, 2010 1:17:24 PM Subject: Re: svn commit: r1029527 [1/2] - in /tomcat/trunk/java/org/apache/catalina: ./ connector/ core/ ha/deploy/ loader/ manager/ mbeans/ realm/ session/ startup/ util/ On 01/11/2010 07:00, Mark Thomas wrote: On 01/11/2010 06:50, Gurkan Erdogdu wrote: Hi; After this commit I am not able to deploy applications using manager OK, I'll take a look. I did some simple tests to make sure nothing major was broken but I didn't test that. As a workaround, just copying the WAR to the webapps directory should work. It won't. looking at it now... Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NamingContext Possible Bug
Konstatin, I think that this is not related with ResourceLink elements. When you define global resource link in your Context.xml, Tomcat creates ResourceLinkRef for this entry. Then same scenario exists, it creates object using ResourceLinkFactory and caches it. It is not desirable. Changing (removing caching statements) this does not break anything. I will open an issue. Regards; --Gurkan - Original Message From: Konstantin Kolinko knst.koli...@gmail.com To: Tomcat Developers List dev@tomcat.apache.org Sent: Fri, September 24, 2010 2:36:46 AM Subject: Re: NamingContext Possible Bug 2010/9/21 Gurkan Erdogdu gurkanerdo...@yahoo.com: Hello folks, In NamingContext implementation, if lookup() is a Reference, current implementation caches the result of the NamingManager # getObjectInstance via following statements and changes the type of the entry. In the following lookups, same object is returned. I would like to write ObjectFactory that returns new instance for each time lookup is called on its reference. But with the current implementation, it is not possible to write such an object factory because of aferomentioned sitaution. I think that entry must be stay as Reference instead of changing entry type. WDYT? There was some discussion previously, proposed and vetoed patch and some issue in bugzilla. [1] From some later code review I think that that code is used to handle ResourceLink elements. That is, when you have a global resource in server.xml and a ResourceLink in your context.xml. [2] It would be undesirable to break that. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=47512 [2] http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#context.xml_configuration Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NamingContext Possible Bug
Hello,
I want to bring this question again.
Why do we change NamingEntry type from REFERENCE to ENTRY? I think that each
lookup must return a new instance. But in this case, it returns the same bound
object instance.
Let's says that we have a Servlet
MyServlet{
private @Resource(name=MyResource) myResource;
...
public blabla(){
new InitialContext().lookup(myResource);
}
}
myResource has injected by the container before @PostConstruct is called. After
that I would like to get a new resource object in blabla() method. It returns
the same injected resource instance instead of creating a new resource.
I think that it must return a different instance from myResource. JNDI tree
of
the Servlet contains MyResource/ResourceRef binding. Therefore each lookup to
MyResource must return a ResourceRef. Becuase it is a reference, context
must call NamingManager.getObjectInstance again to create a new instance.
If this is a bug, I will open an issue.
Thanks;
--Gurkan
- Original Message
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: dev@tomcat.apache.org
Sent: Tue, September 21, 2010 6:30:43 PM
Subject: NamingContext Possible Bug
Hello folks,
In NamingContext implementation, if lookup() is a Reference, current
implementation caches the result of the NamingManager # getObjectInstance via
following statements and changes the type of the entry. In the following
lookups, same object is returned. I would like to write ObjectFactory that
returns new instance for each time lookup is called on its reference. But with
the current implementation, it is not possible to write such an object factory
because of aferomentioned sitaution. I think that entry must be stay as
Reference instead of changing entry type.
WDYT?
NamingContext class:
protected Object lookup(Name name, boolean resolveLinks)
throws NamingException {
.
} else if (entry.type == NamingEntry.REFERENCE) {
try {
Object obj = NamingManager.getObjectInstance
(entry.value, name, this, env);
if (obj != null) {
entry.value = obj;
entry.type = NamingEntry.ENTRY; --- CHANGES type of
the naming entry
}
return obj;
} catch (NamingException e) {
throw e;
} catch (Exception e) {
log.warn(sm.getString
(namingContext.failResolvingReference), e);
throw new NamingException(e.getMessage());
}
}
...
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
NamingContext Possible Bug
Hello folks,
In NamingContext implementation, if lookup() is a Reference, current
implementation caches the result of the NamingManager # getObjectInstance via
following statements and changes the type of the entry. In the following
lookups, same object is returned. I would like to write ObjectFactory that
returns new instance for each time lookup is called on its reference. But with
the current implementation, it is not possible to write such an object factory
because of aferomentioned sitaution. I think that entry must be stay as
Reference instead of changing entry type.
WDYT?
NamingContext class:
protected Object lookup(Name name, boolean resolveLinks)
throws NamingException {
.
} else if (entry.type == NamingEntry.REFERENCE) {
try {
Object obj = NamingManager.getObjectInstance
(entry.value, name, this, env);
if (obj != null) {
entry.value = obj;
entry.type = NamingEntry.ENTRY; --- CHANGES type of
the naming entry
}
return obj;
} catch (NamingException e) {
throw e;
} catch (Exception e) {
log.warn(sm.getString
(namingContext.failResolvingReference), e);
throw new NamingException(e.getMessage());
}
}
...
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NamingContext Possible Bug
Sorry but skip the question!
Thanks;
--Gurkan
- Original Message
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: dev@tomcat.apache.org
Sent: Tue, September 21, 2010 6:30:43 PM
Subject: NamingContext Possible Bug
Hello folks,
In NamingContext implementation, if lookup() is a Reference, current
implementation caches the result of the NamingManager # getObjectInstance via
following statements and changes the type of the entry. In the following
lookups, same object is returned. I would like to write ObjectFactory that
returns new instance for each time lookup is called on its reference. But with
the current implementation, it is not possible to write such an object factory
because of aferomentioned sitaution. I think that entry must be stay as
Reference instead of changing entry type.
WDYT?
NamingContext class:
protected Object lookup(Name name, boolean resolveLinks)
throws NamingException {
.
} else if (entry.type == NamingEntry.REFERENCE) {
try {
Object obj = NamingManager.getObjectInstance
(entry.value, name, this, env);
if (obj != null) {
entry.value = obj;
entry.type = NamingEntry.ENTRY; --- CHANGES type of
the naming entry
}
return obj;
} catch (NamingException e) {
throw e;
} catch (Exception e) {
log.warn(sm.getString
(namingContext.failResolvingReference), e);
throw new NamingException(e.getMessage());
}
}
...
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 Maven Artifacts
Thanks a lot Mark! --Gurkan From: Mark Thomas ma...@apache.org To: Tomcat Developers List dev@tomcat.apache.org Sent: Tue, July 13, 2010 11:14:42 PM Subject: Re: Tomcat 7 Maven Artifacts On 13/07/2010 15:51, Mark Thomas wrote: On 13/07/2010 13:43, Mark Thomas wrote: On 13/07/2010 13:12, Gurkan Erdogdu wrote: Hello Mark; Where is the location? Not able to find http://repo2.maven.org/maven2/org/apache/tomcat/ It looks like the script we have for generating stuff isn't quite right. Henk runs a script that regularly scans the repo for errors and it picked up quite a few with Tomcat 7. I'll see what I can do to fix them but we might end up with some errors remaining for 7.0.0 I know what went wrong and am currently trying to fix it. I'm using the snapshot repo as a test bed since that needs fixing too. It does mean that the snapshot repo is going to get deleted and recreated a few times in the process. I'll drop another note to the list when it is stable again. The 7.0 snapshot is now stable. Also using a new version number of 7.0 rather than 7.0.0. That seemed to make more sense for the snapshots since you end up with 7.0-timestamp On to fixing the 7.0.0 files... Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 Maven Artifacts
Hello Mark; Where is the location? Not able to find Thanks; --Gurkan From: Mark Thomas ma...@apache.org To: Tomcat Developers List dev@tomcat.apache.org Sent: Mon, July 12, 2010 7:03:11 PM Subject: Re: Tomcat 7 Maven Artifacts On 04/07/2010 10:57, Mark Thomas wrote: On 04/07/2010 11:43, Gurkan Erdogdu wrote: Hi folks, Our project OpenWebBeans has a dependency on Tomcat 7 artifacts. We are going to release OWB. Where is the Tomcat 7 Beta Maven artifacts? They haven't been uploaded yet. I should be able to upload them later this week. A bit later than I planned, the 7.0.0 artefacts have been uploaded. Not being a Maven user I don't know how long they'll take to sync. I'd guess up to 24 hours. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat 7 Maven Artifacts
Hi folks, Our project OpenWebBeans has a dependency on Tomcat 7 artifacts. We are going to release OWB. Where is the Tomcat 7 Beta Maven artifacts? Thanks; Gurkan OpenWebBeans PMC Chair
Re: Tomcat and Apache question
Hi; Please use the u...@tomcat.apache.org mailing list for such user questions. Development forum is a place where development related issues are discussed. Thanks; --Gurkan 2010/3/12 westside xpurpleku...@yahoo.com Hi, I am completely new to Tomcat, and I'm trying to setup this module named mod_proxy_html module I have just installed a product called JIRA and I have it working with Tomcat 5.x but I don't think I can install that module without Apache running on my machine. 1. Is Apache required or is just having Tomcat enough? 2. I hear Tomcat is java web server but Apache is a web server also, why would I need to run both? 3.Can you install mod_proxy_html module on a Windows machine without Apache 4. Can Tomcat do everything Apache can do? I'm basically trying to run two applications (JIRA and Confluence) on port 80 and use host headers. I come from the IIS world and I'm looking how to mirror that functionality using JIRA and Tomcat. Any help appreciated. -ws -- View this message in context: http://old.nabble.com/Tomcat-and-Apache-question-tp27873246p27873246.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
About Docs on AntiResource Locking
Hi; In the documentation of context.xml( http://tomcat.apache.org/tomcat-6.0-doc/config/context.html) it says relate with antiResourceLocking attribute: Please note that setting this flag to true in applications that are outside the appBase for the Host (the webapps directory by default) will cause the application to be *deleted* on Tomcat shutdown. You probably don't want to do this, so think twice before setting antiResourceLocking=true on a webapp that's outside the appBase for its Host. I have tried it with Tomcat 6.0.20, but it does not delete application from docBase of the context. It just deletes application from temp/ folder at shutdown. This is also the same for applications running on webapps/ (appBase of the Host). Is this correct behaviour? or did I misunderstand the above explanation? Thanks; --Gurkan
Re: Java EE 6 Web Profile
Hi Kevan; As Mark mentioned, the Geronimo community is building an EE6 Web Profile server and full EE6 profile, also. Current releases of Geronimo already provide custom assemblies which can provide lighter-weight server runtimes (e.g. web container, only) customized to the needs of your application(s). You'd be more than welcome to work with the Geronimo community. Yes, this seems a more reasonable approach :) Maybe I can create some extension for injection JSR-299 beans into Servlets and Filters for Tomcat. Regarding a maven build, Geronimo has a tomcat-archetype which can be used to create a Tomcat maven build environment. You might want to check it out. Really, I do not see it, I will check it. Thanks; --Gurkan 2010/3/2 Kevan Miller kevan.mil...@gmail.com On Mar 1, 2010, at 2:11 AM, Gurkan Erdogdu wrote: Thanks for the answer Mark :) I have started to fork the Tomcat to implement a Java EE Web Profile, called Web Enterprise Server :) My reasons: 1* Without touching source code it is impossible to implement such a product. 2* I also do not like code conventions used in Tomcat (for example , listener-observer model.). I will implement an interfaces and use interfaces on all core modules instead of using implementation classes. 3* I do no like to build it via complex ant scripts. I will create a maven module for each of the projects. I think that each current project will provide one/two modules. Gurkan, As Mark mentioned, the Geronimo community is building an EE6 Web Profile server and full EE6 profile, also. Current releases of Geronimo already provide custom assemblies which can provide lighter-weight server runtimes (e.g. web container, only) customized to the needs of your application(s). You'd be more than welcome to work with the Geronimo community. Regarding a maven build, Geronimo has a tomcat-archetype which can be used to create a Tomcat maven build environment. You might want to check it out. --kevan - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
Re: Java EE 6 Web Profile
Thanks for the answer Mark :) I have started to fork the Tomcat to implement a Java EE Web Profile, called Web Enterprise Server :) My reasons: 1* Without touching source code it is impossible to implement such a product. 2* I also do not like code conventions used in Tomcat (for example , listener-observer model.). I will implement an interfaces and use interfaces on all core modules instead of using implementation classes. 3* I do no like to build it via complex ant scripts. I will create a maven module for each of the projects. I think that each current project will provide one/two modules. Thanks; --Gurkan 2010/2/26 Mark Thomas ma...@apache.org On 26/02/2010 08:55, Gurkan Erdogdu wrote: Hi; You guys , do you think to implement Java EE 6 Web Profile using Tomcat? Or Tomcat is a Servlet JSP container forever? There has been some internal discussion on this topic when a journalist was asking essentially the same question. I think the reply I gave then (that in the end wasn't published) still applies: quote Currently, there are no plans in the Tomcat community to implement the web profile. Tomcat has always been focused on the Servlet and JSP/EL specifications. We simply don't see a demand from the Tomcat community for Tomcat to support the web profile. In my day job at SpringSource, I regularly work with clients that use Tomcat. Some of those clients have a requirement for a JTA implementation but I don't recall any of those clients asking for any of the other components in the web profile. Providing an application server that meets the web profile is on the road map for Apache Geronimo (Tomcat provides the Servlet JSP implementations for Geronimo). The Tomcat committers will continue to listen to the Tomcat community via the very active users discussion list and, if a strong demand for web-profile support in Tomcat emerges, then we would look at the options to provide web profile support at that point. /quote This is my personal view and I'm sure the other committers will speak up if they disagree. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
Java EE 6 Web Profile
Hi; You guys , do you think to implement Java EE 6 Web Profile using Tomcat? Or Tomcat is a Servlet JSP container forever? Thanks; --Gurkan
Removing Listener Based Approach
Hello folks; As you have already know, Tomcat has mainly implemented on Event-Listener mechanism. I think about to remove all of those event-listener mechanism for configuring/starting Tomcat. It is very hard to extend Tomcat without really knowing internal details because you are not able to find which part/parts listen for doing something etc. When using some extended interface and adding methods etc., it will be more structure coding for configuring and starting Tomcat. WDYT? --Gurkan
Minor Error in Documentation
Hello folks; I think that there is a minor error in Tomcat 6 documentation ( http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html). It says that to setup JMX remote access you have to add set CATALINA_OPTS=-Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=%my.jmx.port% \ -Dcom.sun.management.jmxremote.ssl=false \ -Dcom.sun.management.jmxremote.authenticate=false into tomcat startup script. Client does not connect to JMX after adding above setting because quotations marks are put around CATALINA_OPTS=** bla ..bla *. *If you remove everything works as expected. Thanks; --Gurkan
[Tomcat Bayeux and Comet Implementation]
Hi guys; Is there any support for the Bayeux protocol and Comet style application works in the Tomcat 6.x? I looked at the tomcat sandbox and that is this implementations still experimental? Is there any timeline that these components inclueded with tomcat distribution? Thanks; Gurkan Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
