not a geronimo error, but in the sun jdbc-odbc bridge
Stack: [0x33f5,0x33f9), sp=0x33f8f104, free space=252k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [ntdll.dll+0x910e]
C [ODBC32.dll+0xa3ec]
j sun.jdbc.odbc.JdbcOdbc.allocConnect(J[B)J+0
j
The whole debate was a huge fiasco, and unfortunately the one that
screams the most and makes up the best stories win, not necessarily what
is best for the community or the product.
I had no choice but to follow what was going on. I'm not sure what is
going to happen to this code base at this
David Jencks wrote:
On Aug 9, 2007, at 3:58 PM, Filip Hanik - Dev Lists wrote:
David Jencks wrote:
On Aug 9, 2007, at 11:18 AM, threepointsomething wrote:
I am quite new to Geronimo, so I am not sure if the steps I
followed are
right. Here goes:
I had to ensure that the NIO connector
David Jencks wrote:
On Aug 9, 2007, at 11:18 AM, threepointsomething wrote:
I am quite new to Geronimo, so I am not sure if the steps I followed are
right. Here goes:
I had to ensure that the NIO connector is picked up in place of the
basic
HTTP connector, so I made the following change
Jeff Genender wrote:
Ok I added a whole bunch of new connectors in the o.a.g.t.connectors
package.
I am still working on APR - more notes to follow on this as its a little
squirly since the Tomcat Connector somewhat chooses this automatically
based on the existence of a native libraries. For
do none of the spec releases get md5 sums nor pgp signatures?
Filip
Prasad Kashyap wrote:
Please review the specifications located at
http://people.apache.org/~prasad/specs_rc2
The only changes that were made to the binaries that passed a vote
over the past weekend was to add the scm section
I'll give the antlibs another shot
Filip
Jason Dillon wrote:
FYI the issue + patch to the tasks is here:
http://jira.codehaus.org/browse/MANTTASKS-42
--jason
On Mar 29, 2007, at 6:39 AM, Filip Hanik - Dev Lists wrote:
Jason Dillon wrote:
On Mar 27, 2007, at 4:50 PM, Filip Hanik
you resolve them.
Cheers,
--jason
On Mar 30, 2007, at 1:26 PM, Filip Hanik - Dev Lists wrote:
I'll give the antlibs another shot
Filip
Jason Dillon wrote:
FYI the issue + patch to the tasks is here:
http://jira.codehaus.org/browse/MANTTASKS-42
--jason
On Mar 29, 2007, at 6:39 AM
Jason Dillon wrote:
Mocking me? Ha... I prolly deserve it a little :-P
But I'm here if you need more help.
sounds good
Filip
--jason
On Mar 30, 2007, at 4:58 PM, Filip Hanik - Dev Lists wrote:
eeeh, and you were asking why we havent got around to this?
lack of expertise if I remember
Jason Dillon wrote:
On Mar 27, 2007, at 4:50 PM, Filip Hanik - Dev Lists wrote:
I don't expect that Tomcat will switch to m2, though if they are
gonna be publishing m2 repos they should use the m2 antlib for
that. But, looks like the m2 antlib is not up to snuff wrt the new?
apache
if PGP signatures in form of .asc are not required, then we can switch
to the new repo anytime
Filip
Jeff Genender wrote:
Why do they need pgp signatures? That is new to me.
Do you mean SHA1 signatures?
For SHA1 sigs, they can use the sha1 program on minotaur.
They would need to do
Jason Dillon wrote:
On Mar 27, 2007, at 4:04 PM, Dain Sundstrom wrote:
On Mar 27, 2007, at 2:54 PM, Jason Dillon wrote:
On Mar 27, 2007, at 1:58 PM, Filip Hanik - Dev Lists wrote:
Yesterday they marked the issue as resolved since the tomcat jars
are
now available at http://tomcat.apache.org
Looks good, I'm not really the annotations person, but I will put it
directly in his hands.
The word lifecycle is widely used in Tomcat, so we might have to come
up with a better name, to avoid confusion.
Filip
David Jencks wrote:
I've been working on connecting geronimo annotation processing
looks like the patch might introduce some funky dependencies, it got
neglected
http://marc.info/?l=tomcat-devm=117477476413027w=2
The interface lifecycle provider, you put in o.a.catalina, thus creating
a funky relationship.
remember, that other containers use jasper, now they'd have to embed
the first 2 under Verify distribution rights can be marked
Not Applicable.
thanks,
dims
On 2/26/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
cool, sorry to bug, but is there anything more you need from us?
Filip
Davanum Srinivas wrote:
Checked in.
thanks,
dims
On 2/26/07, Filip Hanik
Ladies and Gents,
Just wanted to extend a hand here. If there is any help needed to
integrate TC6 and to make it pass the tests, I am more than willing to
help to get the two platforms working correctly within the timeframe you
are looking at.
Albeit I have a hard time following the volume
we're about to switch, just verifying that everything works the way we
want it,
give it a couple of weeks, and we will be publishing to the main one
Filip
Jason Dillon wrote:
Do we still need the tomcat-m2-repo? Or will the tomcat folks be
using the normal repos like other projects?
Hanik - Dev Lists* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Context level clustering is supported in TC 6
Shiva Kumar H R wrote:
As part of https://issues.apache.org/jira/browse/GERONIMO-2577 I had
opened the following bug in Tomcat:
Context level clustering on 3
maybe I misunderstood you, you are asking if you can shove the Cluster
implementation in a context, the answer to that is no.
6 adds in support of clustering context attributes
Filip
Filip Hanik - Dev Lists wrote:
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster.html
Filip
Shiva Kumar
Jason Dillon wrote:
Okay, hopefully they will get the kinks out soon ;-)
yes, still work in progress :)
Filip
--jason
On Feb 13, 2007, at 4:39 PM, Paul McMahan wrote:
Tomcat currently builds with ant and then manually publish their jars
to a repo at tomcat.apache.org.See
Context level clustering is supported in TC 6
Shiva Kumar H R wrote:
As part of https://issues.apache.org/jira/browse/GERONIMO-2577 I had
opened the following bug in Tomcat:
Context level clustering on 3 or more nodes fails in Tomcat 5.5.20
dims,
I've updated some info in the IP clearance form, attached is the patch file.
The JIRA has also been updated with the codebase that reflects the ASF
license in the source header, and the IBM copyright in the COPYRIGHT.txt
file
Both Covalent and IBM CCLA are also attached to the JIRA item.
the IP clearance form, and attach it to the
JIRA item along with the updated codebase.
We will use this template
http://incubator.apache.org/ip-clearance/ip-clearance-template.html
Once this has been done, we will bring the JIRA to the attention of the
G committers for review.
Filip
Filip Hanik
This is the formal vote to accept the J2G codebase and bring it through
incubation (see
http://marc.theaimsgroup.com/?l=geronimo-devm=116906208022256w=2)
The final destination is to be part of the geronimo devtool subproject.
(see
Kevan Miller wrote:
On Jan 31, 2007, at 12:30 PM, Filip Hanik - Dev Lists wrote:
Kevan Miller wrote:
On Jan 31, 2007, at 10:10 AM, Filip Hanik - Dev Lists wrote:
This is the formal vote to accept the J2G codebase and bring it
through incubation (see
http://marc.theaimsgroup.com/?l
anything that is needed to the JIRA item
Filip
-dain
On Jan 31, 2007, at 7:10 AM, Filip Hanik - Dev Lists wrote:
This is the formal vote to accept the J2G codebase and bring it
through incubation (see
http://marc.theaimsgroup.com/?l=geronimo-devm=116906208022256w=2)
The final destination
So far we have received a few positive comments, no negative and no vetos.
So are we ok with this donation and ready to move forward, possible into
incubation?
Filip
Kevan Miller wrote:
On Jan 17, 2007, at 10:33 AM, Alex Karasulu wrote:
+1 on the CCLA's with a patch submission. If it's a
.
Covalent's CCLA has been uploaded to JIRA
https://issues.apache.org/jira/browse/GERONIMO-2743
Filip
Filip Hanik - Dev Lists wrote:
IBM has together with in a joint effort with Covalent developed a
JBoss to Geronimo conversion tool. This tool is used when converting
applications from JBoss
Dain Sundstrom wrote:
On Jan 16, 2007, at 12:19 PM, Filip Hanik - Dev Lists wrote:
IBM has together with in a joint effort with Covalent developed a
JBoss to Geronimo conversion tool. This tool is used when converting
applications from JBoss to Geronimo, and automatically converts
IBM has together with in a joint effort with Covalent developed a JBoss
to Geronimo conversion tool. This tool is used when converting
applications from JBoss to Geronimo, and automatically converts the
configuration file from one app server to the other.
We feel that this piece of software
Jacek Laskowski wrote:
On 1/16/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
IBM has together with in a joint effort with Covalent developed a JBoss
to Geronimo conversion tool. This tool is used when converting
applications from JBoss to Geronimo, and automatically converts
really awesome work Gianny, I know you've worked very hard on it.
Filip
David Jencks wrote:
Wow this is great!!
Are there instructions somewhere on how to set up a demo system?
Having an integration test would be even better :-)
thanks
david jencks
On Jan 6, 2007, at 7:30 PM, Gianny
Tomcat 6 is just around the corner, but is pretty easy to build from
SVN, three steps,
1. svn co https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ trunk
2. cd trunk
3. ant download
4. ant
It generates all the libraries that you'll need, more answers inline
Joe Bohn wrote:
JSTL 1.2 is
I addressed the discussion about what transport do we use, a long time
ago by creating an agnostic API to plug into.
http://marc.theaimsgroup.com/?l=geronimo-devm=115281186718399w=2
http://people.apache.org/~fhanik/geronimo-cluster-api.zip
this way, we can continue the pluggability of G, and
Cool, thanks for posting this.
While I do believe everything in this API is very useful, I see it as an
extension to the one I created.
My API is only about the cluster, and its meta data, while the API below
is very session oriented.
In a cluster without state replication, most of the
no.
you should wait at least couple of days to let people review it, then
vote, then summarize the votes :)
otherwise you wont give people a chance
Filip
Jeff Genender wrote:
Thats 3! Ok...as soon as the new trunk is cut, I will merge in the
session API.
Thanks!
Jeff
Alan D. Cabrera
Jules Gosnell wrote:
David Blevins wrote:
On May 4, 2006, at 12:57 AM, Jules Gosnell wrote:
Sort of. Both your explanations involve smartening the java clients
on the other end of WS or CORBA to play nice.
??
smart java stubs for RMI over OpenEJB-protocol (what is it called?) or
its a neat solution, I like it.
one would still need to build the aggregate view, so that summaries
etc can be reported on,
otherwise you only view a server at a time, which can be achieved by
just connecting to the server itself.
by aggregate I mean the sum of the nodes in the cluster, for
and David J had previously
discovered some issues that required significant rework that he didn't
want to tackle until G1.2..
So... Do we stick with 5.5.9 for G1.1 and move to 5.5.16+ in G1.2?
Thanks
-Dave-
Filip Hanik - Dev Lists wrote:
looks like you are right, there where some other fixes
Clustering was broken in Tomcat 5.5.10-5.5.15 due to a protocol change,
this was corrected in 5.5.16.
I would run the tests again that version, and then I can help you out
with any problems you run into.
Filip
Dave Colasurdo wrote:
Jeff,
Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and
Dave Colasurdo wrote:
Jeff,
Upgraded tomcat, tomcat_ajp and jasper to 5.5.15 and ran the
clustering tests.
The *good* news...
Load balancing, sticky session, session replication and session
failover seem to work using the same deployment plan that was created
for G1.1 w/ TC 5.5.9..
The
Colasurdo wrote:
Thanks Filip!!
http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED]
seems to indicate that it is fixed in 5.5.15..
Is it fixed in 5.5.15 or 5.5.16?
Thanks
-Dave-
Filip Hanik - Dev Lists wrote:
Clustering was broken in Tomcat 5.5.10-5.5.15 due
network. I will try to know and
update you on this.
To my surprise, when I tested on only windows machines, this problem
is not there. It is experienced only on Linux machines.
Thanks
Phani
On 3/30/06, *Filip Hanik - Dev Lists* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED
gentlemen,
looks like there is an attribute missing from the
Cluster...*Receiver.../*/Cluster element.
the ReplicationListener.listen() method just gets the listen address (or
tries to resolve the name, then gets the port)
then it starts up a server socket using NIO.
the other error, no
that the attribute is missing all together.
Filip
Jeff Genender wrote:
Filip,
Thanks for the input...any idea on the missing attribute?
Jeff
Filip Hanik - Dev Lists wrote:
gentlemen,
looks like there is an attribute missing from the
Cluster...*Receiver.../*/Cluster element
/attribute
/gbean
Phani, did you change the tcpListenAddress initParams attribute to a
real address?
Jeff
Filip Hanik - Dev Lists wrote:
it would be one of these, they should all be set to a value.
tcpListenAddress=auto
tcpListenPort=9015
tcpSelectorTimeout=100
tcpThreadCount=6
also
also in the place of implementing a regular ReplicatedMap, to use
for context attribute replication, a feature sought after.
I will subscribe to the WADI list and we can continue over there re:
session management.
Filip
Jules Gosnell wrote:
Filip Hanik - Dev Lists wrote:
gentlemen
gentlemen, not a committer here, but wanted to share some thoughts.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
the solution that we plan to
gentlemen, not a committer here, but wanted to share some thoughts.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
the solution that we plan to
Hi Dain,
let me address the location, and show you how the location is completely
transparent.
The way the LazyReplicatedMap works is as follows:
1. Backup node fails - primary node chooses a new backup node
2. Primary node fails - since Tomcat doesn't know which node the user
will come to
node to account for false positive.
the only scenario that is not accounted for is when you have a wacky lb
that sends two parallel requests to two different servers. this would
require distributed locking, and that is a path that is too much
overhead to walk down.
Filip
Filip Hanik - Dev
51 matches
Mail list logo
