Hi All;
As I promise I have send a patch that fix the basic problems
(hardcoded obj names ..ect ) in the Axis geronimo module and get the
POJO case up and runing :).
The patch is checked in; I am looking foward to the comments to know
am I heading in the right direction. (I am busy with a exam
I am looking forward to looking at the new code very much and hope that
I can quickly finish up what I've been working on so I can concentrate
on the new code properly.
Many thanks,
david jencks
On Nov 3, 2004, at 8:39 PM, Srinath Perera wrote:
Hi All;
As I promise I have send a patch that fix
Dynamic gbean attributes don't have type information
Key: GERONIMO-432
URL: http://nagoya.apache.org/jira/browse/GERONIMO-432
Project: Apache Geronimo
Type: Bug
Components: kernel
Versions: 1.0-M2
[
http://nagoya.apache.org/jira/browse/GERONIMO-334?page=comments#action_55022 ]
John Sisson commented on GERONIMO-334:
--
I noticed that the following issue has a patch to use the eclipse compiler for
Jetty:
Thanks David :) I am listing what might helpful for you to review.
(no hurry . even I like to have about two weeks time to get the
real thing started).
1) new code has removed alll the hardcoded obj names.
2)At the test cases I do manually initaite the GBeans that would
started by the plan
[ http://nagoya.apache.org/jira/browse/GERONIMO-432?page=history ]
David Jencks closed GERONIMO-432:
-
Resolution: Fixed
Fix Version: 1.0-M3
Fixed, and used for Activation specs and resource adapters/managed connection
factories.
Dynamic
[ http://nagoya.apache.org/jira/browse/GERONIMO-432?page=history ]
David Jencks reassigned GERONIMO-432:
-
Assign To: David Jencks
Dynamic gbean attributes don't have type information
+1
Gianny
On 4/11/2004 3:48 AM, Jeremy Boynes wrote:
On the belief we need to formally vote on making a release, should we
produce a M3 release?
Aaron,
Here's my paste: http://rafb.net/paste/results/I89rnj81.html. If you
look closely, there's some problem loading commons logging stuff in
your environment.
24: [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
25: [java] [DEBUG] Class
Believe it or not, it looks like only the first JAR in the
dependency list is getting onto the classpath. When I put a little
wrapper JAR there first, none of the EWS stuff could be loaded. If I take
that away, EWS is first and Logging can't be loaded. I need to figure out
WTF is going
No problem at all, on the upside, ews cvs/build now uses the same
commons-logging that geronimo does AND there are a whole bunch of
printStackTrace and log.error to make it easy the next time Axis/EWS
breaks something :)
-- dims
On Thu, 4 Nov 2004 07:43:57 -0500 (EST), Aaron Mulder
[EMAIL
hmmm...let me check by cleaning up my axis repo.
On Thu, 4 Nov 2004 08:08:12 -0500 (EST), Aaron Mulder
[EMAIL PROTECTED] wrote:
No, never mind, I jsut had a corrupted EWS download that time.
OK, so how I'm looking at the build script for
It works for me now. Thank you very much!
I guess maybe one of our (by which I mean David B's) standard
builds should wipe out its maven repository before building. The first
time developer experience.
Aaron
On Thu, 4 Nov 2004, Davanum Srinivas wrote:
Yoohoo!!! Fixed it.
[
http://nagoya.apache.org/jira/browse/GERONIMO-334?page=comments#action_55044 ]
Dain Sundstrom commented on GERONIMO-334:
-
Yes. My primary motivation for working on switching to the eclipse compiler
was so we would no longer need the
Dear Early Adopters,
If you have tried Geronimo already (or in the process of doing so),
please let us know how we can make it easier Out-Of-The-Box for
everyone...Here are some things we jotted down to get the ball
rolling:
http://wiki.apache.org/geronimo/WishList/M3
thanks,
dims
--
Davanum
Tolerate non-Sun JREs
-
Key: GERONIMO-433
URL: http://nagoya.apache.org/jira/browse/GERONIMO-433
Project: Apache Geronimo
Type: Improvement
Components: general
Reporter: Glyn Normington
Priority: Critical
Geronimo fails to build
Connection factories extracted from conceptually wrong gbean
Key: GERONIMO-434
URL: http://nagoya.apache.org/jira/browse/GERONIMO-434
Project: Apache Geronimo
Type: Bug
Versions: 1.0-M2
[ http://nagoya.apache.org/jira/browse/GERONIMO-434?page=history ]
David Jencks updated GERONIMO-434:
--
Component: connector
Connection factories extracted from conceptually wrong gbean
[
http://nagoya.apache.org/jira/browse/GERONIMO-433?page=comments#action_55049 ]
Aaron Mulder commented on GERONIMO-433:
---
The Geronimo Jetty HTTPSConnector also assumes Sun's JRE (by using the Sun JSSE
provider). I believe Jetty has a generic
Should be able to specifiy default parent config id
---
Key: GERONIMO-435
URL: http://nagoya.apache.org/jira/browse/GERONIMO-435
Project: Apache Geronimo
Type: Improvement
Reporter: Jeremy Boynes
Assigned to:
I'm trying to detect a Zip file. On an Intel/AMD platform, the
first 4 bytes are (hex) 50-4b-03-04. I wonder if the order is different
on a differently-endian platform. Can someone look at a ZIP file on,
what, a Solaris box I guess, and let me know what order the first 4 bytes
are?
[ http://nagoya.apache.org/jira/browse/GERONIMO-433?page=history ]
Alan Cabrera reassigned GERONIMO-433:
-
Assign To: Alan Cabrera
Tolerate non-Sun JREs
-
Key: GERONIMO-433
URL:
Aaron Mulder wrote:
I'd like to be able to add entries to config.list when the server
is not running and I'm doing a deployment. The problem is, the
configuration list GBean isn't running -- it's not in the minimal set
started by the deployer. And even if it was, it would install a shutdown
The addition of GBean persistence has revealed a problem in ServerInfo
(http://nagoya.apache.org/jira/browse/GERONIMO-431). The problem is
that normally we guess the location of the geronimo home directory, and
this location is saved as an absolute path during gbean persistence.
This means
On Nov 4, 2004, at 11:18 AM, Jeremy Boynes wrote:
Aaron Mulder wrote:
I'd like to be able to add entries to config.list when the server is
not running and I'm doing a deployment. The problem is, the
configuration list GBean isn't running -- it's not in the minimal set
started by the deployer.
I'm working on the new deployer not the old one. As per the
proposed deployer syntax message, this one actually offers a JSR-88
start method while the server is not running, which equates to updating
the config list to include the module. I'd rather not start the server to
do that...
Aaron Mulder wrote:
I'm working on the new deployer not the old one. As per the
proposed deployer syntax message, this one actually offers a JSR-88
start method while the server is not running, which equates to updating
the config list to include the module. I'd rather not start the server to
Hi,
I just want to try M3 with Tomcat and Apache web server. I've running
Tomcat with the web server, now I'd need step-by-step instructions (1.)
to get geronimo running with my installation (2.) how to deploy an
application into geronimo (especially for additional geronimo
configuration
On Thu, 4 Nov 2004, Jeremy Boynes wrote:
Pardon me for being dumb but how can you start a module if the server is
down?
I think we may be trying to hard to kludge 88-style operations into a
mode that 88 was not intended to support.
If you deploy to a server that's not running,
Aaron Mulder wrote:
If you deploy to a server that's not running, then the module
will be started next time the server starts. If you distribute to a
server that's not running, then the module will not be started next time
the server starts.
You mean, you hope that it starts - you would have
Don't you mean M4? We just voted to release M3 now.
-David
On Nov 4, 2004, at 8:49 AM, Davanum Srinivas wrote:
Dear Early Adopters,
If you have tried Geronimo already (or in the process of doing so),
please let us know how we can make it easier Out-Of-The-Box for
everyone...Here are some things
What I am proposing is the equivalent of using the current deploy
tool, and then adding the module's configId to the server command line
next time you start it -- which is what you can do today. I don't see how
that makes the situation worse.
You seem to be sugesting that the
JSR-88: Targets Ignored
---
Key: GERONIMO-436
URL: http://nagoya.apache.org/jira/browse/GERONIMO-436
Project: Apache Geronimo
Type: Bug
Components: deployment
Versions: 1.0-M2
Reporter: Aaron Mulder
The current JSR-88 deployer
Aaron Mulder wrote:
What I am proposing is the equivalent of using the current deploy
tool, and then adding the module's configId to the server command line
next time you start it -- which is what you can do today. I don't see how
that makes the situation worse.
No, you were proposing having
sorryM4 it is.
-- dims
On Thu, 4 Nov 2004 11:55:51 -0800, David Blevins [EMAIL PROTECTED] wrote:
Don't you mean M4? We just voted to release M3 now.
-David
On Nov 4, 2004, at 8:49 AM, Davanum Srinivas wrote:
Dear Early Adopters,
If you have tried Geronimo already (or in
[
http://nagoya.apache.org/jira/browse/GERONIMO-437?page=comments#action_55059 ]
toby cabot commented on GERONIMO-437:
-
forgot to mention: if I run the build so that it doesn't run the unit tests
then it succeeds but I get a similar stack trace
On Thu, 4 Nov 2004, Jeremy Boynes wrote:
No, you were proposing having the deployment tool hack the internal file
used by a specific GBean. I object to that as it relies on
implementation detail.
Hmm. Obviously we're not on the same page here.
So you would be totally
About Axis, J2EE 1.4 mandates several web services jsr's and we have
to make it work seemlessly with the rest of the system. I apologize
for the geronimo-axis module breaking builds. If Axis breaks i will
fix it ASAP or comment it out myself in the project.properties.
thanks,
dims
On Thu, 04
Looks like to be the same issue as
http://nagoya.apache.org/jira/browse/GERONIMO-408
-- Ralf
Aaron Mulder wrote:
For what it's worth, I can't recall having a problem with Tomcat,
JBoss or WebLogic where it processed a partially copied file or had a race
condition or was unable to revert or it was unclear to me whether the
application was successfully deployed (either you get big stack
Axis may be required for J2EE 1.4 compliance, but I don't think that
necessarily translates into one very large build containing every
component.
If someone is working on the Axis integration, then why should they be
held up because of a problem with the integration of some other module.
If
ok
On Thu, 04 Nov 2004 15:11:17 -, David Farb [EMAIL PROTECTED] wrote:
Axis may be required for J2EE 1.4 compliance, but I don't think that
necessarily translates into one very large build containing every
component.
If someone is working on the Axis integration, then why should
On Nov 4, 2004, at 12:52 PM, Jeremy Boynes wrote:
Aaron Mulder wrote:
For what it's worth, I can't recall having a problem with Tomcat,
JBoss or WebLogic where it processed a partially copied file or had a
race
condition or was unable to revert or it was unclear to me whether the
application was
My gut feeling is that would be more trouble then it is worth. The
project still must build the tree every day, so we know that the source
is consistent. Also, before someone commits code they must build the
whole tree to make sure they didn't introduce a subtle bug.
-dain
--
Dain Sundstrom
On Nov 4, 2004, at 3:07 PM, Aaron Mulder wrote:
I talked to Jeremy. Our plan for now is that I will check in a
deployer tool that includes the following features:
- everything, when working online (on the same PC as the server)
- package and distribute, when working offline (on the same
On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote:
It is covered in the subversion book http://svnbook.red-bean.com/
Can understand why you would want to branch for security, but I think
you should keep working on your deployment stuff in the main trunk.
If it's easy to fold back in, why not do in
46 matches
Mail list logo
