Web Service: Error while publishing modules,
org.apache.geronimo.kernel.InternalKernelException
---
Key: GERONIMODEVTOOLS-13
URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-13
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-13?page=all ]
Miguel A Paraz updated GERONIMODEVTOOLS-13:
---
Attachment: eclipse-trace5.txt
Trace including the ClassNotFound/RMI exception.
Web Service: Error while publishing modules,
On Aug 31, 2005, at 2:26 AM, Dain Sundstrom wrote:
Good idea. Alternatively for our use, it looks like the directory
project has its own asn1 implementation. IIUC that is all we use
in the openejb corba code. Can we sidestep this problem by using
the directory's asn1 implementation?
[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-13?page=comments#action_12329834
]
Sachin Patel commented on GERONIMODEVTOOLS-13:
--
Can you disable trace on the wst plugin and use the options file in the
[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-13?page=comments#action_12329835
]
Sachin Patel commented on GERONIMODEVTOOLS-13:
--
Is geronimo-kernel-1.0-M4.jar included in the lib directory of
org.apache.geronimo.runtime.v1 plugin?
Right, so deleting doesn't remove anything.
I think that hiding our history like this is a bad idea, and will
lead to even more confusion - if you don't want to make a mistake and
work on a branch accidentally, don't check it out.
Anyway, I can't see how removing the branch will prevent
On Sep 18, 2005, at 7:59 PM, Alan D. Cabrera wrote:
Aaron Mulder wrote, On 9/18/2005 4:51 PM:
OK. I still have stuff I want to get in, but I can add it to both
M5 and HEAD.
-1 one should not be adding features to two branches.
But fixes we do... for example, I still have to get
Is there any chance you can just take what you have, and donate that
and keep working on it here?
We could have spent the last month working together, you doing the
work that you wanted to do, and us reading the code, asking
questions, etc. We promise we won't get in your way too much :)
I agree with Geir in that I think that we should have kept the branch;
even though it is widely accepted that we will not extend it with a
patch, it's just good form to do things in a consistent standard way.
What confused me when I responded to Dain's original request was the QA
suffix.
[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-13?page=comments#action_12329846
]
Sachin Patel commented on GERONIMODEVTOOLS-13:
--
Thanks. Looks like you are running on Java 5. This may be the problem. You
need to build and launch
Geir Magnusson Jr. wrote, On 9/19/2005 6:32 AM:
On Sep 18, 2005, at 7:59 PM, Alan D. Cabrera wrote:
Aaron Mulder wrote, On 9/18/2005 4:51 PM:
OK. I still have stuff I want to get in, but I can add it to both
M5 and HEAD.
-1 one should not be adding features to two branches.
But
On Sep 19, 2005, at 9:42 AM, Alan D. Cabrera wrote:
Geir Magnusson Jr. wrote, On 9/19/2005 6:32 AM:
On Sep 18, 2005, at 7:59 PM, Alan D. Cabrera wrote:
Aaron Mulder wrote, On 9/18/2005 4:51 PM:
OK. I still have stuff I want to get in, but I can add it to
both M5 and HEAD.
-1
[
http://issues.apache.org/jira/browse/GERONIMO-918?page=comments#action_12329854
]
David Jencks commented on GERONIMO-918:
---
Fixed in head:
Sending
modules/axis-builder/src/java/org/apache/geronimo/axis/builder/AxisBuilder.java
Sending
[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12?page=comments#action_12329864
]
Miguel A Paraz commented on GERONIMODEVTOOLS-12:
Found severs.xml and cleaned it.
So this issue is not specific to Web Services but due to WST
Geir, if your statement were factually correct I would agree with
you, but we have not lost or hid any history. Go see for yourself.
$ cd tags/v1_0_M4
$ svn log project.properties
or
http://svn.apache.org/viewcvs.cgi/geronimo/tags/v1_0_M4/
project.properties?rev=227113view=log
You will
On Sep 19, 2005, at 6:36 AM, Alan D. Cabrera wrote:
I agree with Geir in that I think that we should have kept the
branch; even though it is widely accepted that we will not extend
it with a patch, it's just good form to do things in a consistent
standard way.
Well given that Geir was
On 9/19/05, Alan D. Cabrera [EMAIL PROTECTED] wrote:
Agreed, bug fixes we do put into both branches.However, Aaron istalking about features, IIUC.Just to be succinct, my -1 is a real technical veto on adding features,not bug fixes, to both branches; though I am not intransigent and am
willing to
On Sep 19, 2005, at 11:17 AM, Dain Sundstrom wrote:
Geir, if your statement were factually correct I would agree with
you, but we have not lost or hid any history. Go see for yourself.
I never said we lost anything. We are hiding it because you can't go
look at our structure of branches
On 9/19/05, Aaron Mulder [EMAIL PROTECTED] wrote:
On 9/19/05, Alan D. Cabrera [EMAIL PROTECTED] wrote:
Agreed, bug fixes we do put into both branches. However, Aaron is
talking about features, IIUC.
Just to be succinct, my -1 is a real technical veto on adding features,
not bug fixes,
On 9/19/05, Aaron Mulder [EMAIL PROTECTED] wrote:
Well, I've accepted all along that I have more things I want to get in than
most people. I don't think there's widespread agreement to hold the branch
until I'm done. At some point it will go into a real freeze mode and then
I'll stop
[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-13?page=comments#action_12329877
]
Miguel A Paraz commented on GERONIMODEVTOOLS-13:
It works. Sorry about that. I didn't see any mention of the JDK 1.4 requirement.
Web Service:
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-13?page=all ]
Sachin Patel resolved GERONIMODEVTOOLS-13:
--
Resolution: Invalid
Assign To: Sachin Patel
Web Service: Error while publishing modules,
Here is the screen output:
jar:install:
build:end:
build:start:
default:
java:prepare-filesystem:
[mkdir] Created dir:
C:\projects\geronimo\modules\axis-builder\target\classes
Adding to classpath: C:\Documents and
This is a subject with too much heat and smoke and weird accusations
of commercial motivations to boot, so lets just have this out and
keep moving.
I have heard from two people that my position appears either entirely
or partially influenced by IBMs interest in offering support for a
Actually, IIUC, branches and tags don't waste space (at least, not on
the server). SVN doesn't create copies of the files in the repo
until they are actually changed vs the source of the copy (which for a
tag would be never).
For my part, I don't understand why we don't keep branches alive
I think we, the community, needs to decide if we want to maintain
milestones going forward. This would include we shouldn't but we
might want to... (1) If we are maintaining milestones, I think we
should have the following structure:
branches/v1_0_M5
tags/v1_0_M5_0
This makes it clear
On Sep 19, 2005, at 3:05 PM, Aaron Mulder wrote:
BTW, I think the implication that IBM has something to do with
deciding on a branching strategy is ridiculous. But I don't know
who made it or why, so perhaps that's a premature statement on my
part. :)
I brought it up to get it out
On Sep 19, 2005, at 12:05 PM, Aaron Mulder wrote:
As for the confusion of branches and tags, Dain, can you clarify if
your confusion is caused strictly by this being a milestone release?
[rearranged]
But of course there is no M4.0 and M4.1 so the whole issue is kind
of muddy regarding
On Sep 19, 2005, at 12:05 PM, Aaron Mulder wrote:
For my part, I don't understand why we don't keep branches alive
forever, or at least until we vote on discontinuing support for the
release the branch is tied to. We can vote to trash M4 in favor of
M5 if we like, but I don't think 24
I can't argue with that! :)
AaronOn 9/19/05, Dain Sundstrom [EMAIL PROTECTED] wrote:
On Sep 19, 2005, at 12:05 PM, Aaron Mulder wrote: For my part, I don't understand why we don't keep branches alive forever, or at least until we vote on discontinuing support for the release the branch is tied
The problem is here:
org.apache.geronimo.common.DeploymentException: No reference named
ORBRefs in gbean openejb:type=Server,name=EJB
It seems like your Geronimo and OpenEJB code might be out of sync? Do
you have the OpenEJB code checked out (e.g. using maven m:co)? If
so, have you updated it
I'd prefer sandbox until the ear is building properly. The reason I put
it in now (with a deployable ear) was to work in the public and not wait
till everything was perfect. Comments on the maven pieces greatly
appreciated. I have some hardcoded versions in there. I have to
restructure
Before we discuss this to death, I propose:
* we drop the M5 branch altogether
* we fix any CTS regressions (once rather than twice)
this also gives Aaron a couple more days to finish up his features
* we create a 1.0 branch
* we make sure it still passes CTS, then tag it and release as 1.0.0
+1000
Hell yeah!
-dain
On Sep 19, 2005, at 5:14 PM, Jeremy Boynes wrote:
Before we discuss this to death, I propose:
* we drop the M5 branch altogether
* we fix any CTS regressions (once rather than twice)
this also gives Aaron a couple more days to finish up his
+1
As I've said during M4, Alright, IMHO, we've outgrown milestones
See Thinking beyond 1.0, http://www.mail-archive.com/
dev@geronimo.apache.org/msg06953.html
Let's do this!
-David
On Sep 19, 2005, at 5:14 PM, Jeremy Boynes wrote:
Before we discuss this to death, I propose:
* we drop
You must be joking!!! Have you tried at the console recently? It's
like 50% there.
I'm sorry, I'll be happy to call this RC1 or 0.9 or whatever, but I'm
WAY not ready to call it 1.0. There are also a ton of JIRA issues
that need to be at least looked at before 1.0. Plus, like it or not,
I
I agree with Jeremy and Aaron. I think we need some additional
performance work in addition to the console and probably some minor
features. I'd prefer to make this V0.9.5 that is certified as a
technology preview with a statement that the console and other features
will be coming in the
I think we need to finalize our plan for Tomcat and Jetty for M5 (or
whatever we call it).
I believe we agreed earlier to produce separate Tomcat and Jetty releases.
Currently, our modules/assembly build creates a distribution with
BOTH Tomcat and Jetty, and I believe even starts both by default
+1 on what Matt says...and i will take it a step further. Instead of
MX, why not let this next one be the RC1?
Jeff
Matt Hogstrom wrote:
I agree with Jeremy and Aaron. I think we need some additional
performance work in addition to the console and probably some minor
features. I'd prefer
Man. I agree with everyone here, a little :)
I'd love to see the milestone nomenclature abandoned.
I'd also love to see us knock a few corners off and get the console
working before a 1.0
So ideally, I'd love to see this as 0.9, and we all commit to focus
on a very quick cycle to 1.0
Non-persistent attributes shouldn't default to manageable
-
Key: GERONIMO-1017
URL: http://issues.apache.org/jira/browse/GERONIMO-1017
Project: Geronimo
Type: Bug
Components: kernel
Versions: 1.0-M5
Jeff Genender wrote:
+1 on what Matt says...and i will take it a step further. Instead of
MX, why not let this next one be the RC1?
To me an RCx implies feature freeze and bugfixes only and it doesn't
sound like we mean that here given the console is 50% done.
Actually, if that is the
-1 I'm not willing to put out a crappy 1.0 release. Sorry.
I'm perfectly happy to go with RC1 or M5 or 0.9.x.
Aaron
On 9/19/05, Jeremy Boynes [EMAIL PROTECTED] wrote:
To me an RCx implies feature freeze and bugfixes only and it doesn't
sound like we mean that here given the console is 50%
Jeremy Boynes wrote:
Jeff Genender wrote:
+1 on what Matt says...and i will take it a step further. Instead of
MX, why not let this next one be the RC1?
To me an RCx implies feature freeze and bugfixes only and it doesn't
sound like we mean that here given the console is 50% done.
I
Aaron Mulder wrote:
-1 I'm not willing to put out a crappy 1.0 release. Sorry.
I'm perfectly happy to go with RC1 or M5 or 0.9.x.
+1 for what Aaron says.
Aaron
On 9/19/05, Jeremy Boynes [EMAIL PROTECTED] wrote:
To me an RCx implies feature freeze and bugfixes only and it doesn't
On 9/19/05, Jeff Genender [EMAIL PROTECTED] wrote:
...
So let me take back my RCx statement. I would think we let this last M5
go (because we promised it and have already went through the motions),
and then define what is 1.0. Lets do the RCx...minimum 2 rounds (RC1
and RC2), and try to
Clarification of references
---
Key: GERONIMO-1018
URL: http://issues.apache.org/jira/browse/GERONIMO-1018
Project: Geronimo
Type: Improvement
Components: kernel
Versions: 1.0-M5
Reporter: Aaron Mulder
Fix For: 1.0-M5
[ http://issues.apache.org/jira/browse/GERONIMO-1018?page=all ]
Aaron Mulder updated GERONIMO-1018:
---
Description:
Why is it that this works:
references
pattern
gbean-namegeronimo.server:name=Foo,*/gbean-name
/pattern
/references
But this
Ahh, guys, you do realize that 0.9.x is actually backwards from 1.0-FOO.
If anything, can we at least agree that math will be part of our
version numbers?
-David
On Sep 19, 2005, at 6:08 PM, Geir Magnusson Jr. wrote:
Man. I agree with everyone here, a little :)
I'd love to see the
Alright guys, we're talking over each other again and are too far
down in the details.
This entire thing started as Geir wanted to do 1.0-M5.1, 1.0-M5.2,
1.0-M5.3, ... 1.0-M5.N while we all work on 1.0-M6 (or whatever).
That's not a bad goal, but we have to agree on what we are going for
[
http://issues.apache.org/jira/browse/GERONIMO-1015?page=comments#action_12329945
]
Aaron Mulder commented on GERONIMO-1015:
Main fix with Jetty support in revision 290359
Management API: Web Logging
---
Key:
[ http://issues.apache.org/jira/browse/GERONIMO-1015?page=all ]
Aaron Mulder updated GERONIMO-1015:
---
Fix Version: 1.0-M5
Environment: (was: all)
Management API: Web Logging
---
Key: GERONIMO-1015
[
http://issues.apache.org/jira/browse/GERONIMO-1015?page=comments#action_12329947
]
Aaron Mulder commented on GERONIMO-1015:
Still need to remove the no-longer-used portlet helper classes, and confirm
that all the search criteria work properly (I
53 matches
Mail list logo
