On Sun, 7 Nov 2004, Jeremy Boynes wrote:
> ...
> If someone implements this (dealing, of course, with all the nasties)
> then all the better; in fact, IIRC there is some old scanning code of
> mine lying around in the repo somewhere.
>
> However, due to the technical issues I would still not adv
I think there is a misconception here between what is supported and what
is recommended. There have been a lot of bad ideas in the past (EJB1.0
DD anyone?) and people have tried to improve on them. I don't think we
need to make bad ideas from the past the recommended way of doing things
even if
Thanks to everyone for their help. Mucho gracia!
Michael
On Sun, 7 Nov 2004, David Jencks wrote:
> I don't think "drop, wait & wonder" hot deployment should be supported.
> This only supports deployment of applications with embedded plans or
> applications that need no plan.
I don't understand the objections to this. "embedded plans" is
On Sun, 7 Nov 2004, David Jencks wrote:
> I'm not exactly ready to vote -1, but I think we should resolve these
> issues before M3:
>
> 1. http://issues.apache.org/jira/browse/GERONIMO-386 Make cmp work with
> derby. Prove it with the itests
>
> 2. http://issues.apache.org/jira/browse/GERONIMO
XAResource.setTransactionTimeout never called
-
Key: GERONIMO-452
URL: http://nagoya.apache.org/jira/browse/GERONIMO-452
Project: Apache Geronimo
Type: Bug
Components: transaction manager
Versions: 1.0-M2
Re
[ http://nagoya.apache.org/jira/browse/GERONIMO-378?page=history ]
David Jencks closed GERONIMO-378:
-
Resolution: Fixed
Fix Version: 1.0-M3
We've heard that the omission of thread local tx timeout from the latest jta
spec is a mistake. UserTr
TranQL uses TM directly to avoid any dependency on Geronimo.
IIRC the only place it is used is to support collection-valued accessors
for EJBs - the spec requires that at the end of the transaction any
returned Collections become inoperative. Have look at MultiValuedCMRAccessor
Alternatively you
Thank you Jeremy, this is a very clear explanation of the
architecture. I agree completely with your point of view. I think we
should get some version of this explanation on the wiki.
I apologize for not entering this discussion earlier, but I didn't have
time to think through the issues
I'm not exactly ready to vote -1, but I think we should resolve these
issues before M3:
1. http://issues.apache.org/jira/browse/GERONIMO-386 Make cmp work with
derby. Prove it with the itests
2. http://issues.apache.org/jira/browse/GERONIMO-402 finish separating
deployment code and runtime co
The TransactionContextManager has a getTransactionManager method that
returns the underlying TransactionManager. This is used only by
EJBModuleImpl to give the tmDelegate. I haven't looked but I think
this is used by tranql/cmp.
This seems wrong to me. I think it could result in the transact
Michael G. McGrady wrote:
Does anyone have a correct URL to the geronimo lists subscriptions?
Thanks.
Michael McGrady
In general:
mailto:[EMAIL PROTECTED]
e.g. mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
--
Jeremy
Are you having trouble with the ones here:
http://wiki.apache.org/geronimo#head-4e506cc0e4cdde5ada4b384308059f2d634d1d7e
Aaron
On Sun, 7 Nov 2004, Michael G. McGrady wrote:
> Does anyone have a correct URL to the geronimo lists subscriptions? Thanks.
Does anyone have a correct URL to the geronimo lists subscriptions? Thanks.
Michael McGrady
On Nov 7, 2004, at 2:39 PM, Bruce Snyder wrote:
Geir Magnusson Jr. wrote:
On Nov 7, 2004, at 1:21 PM, Bruce Snyder wrote:
Per these disagreements, I think that we should address them before
we move on simply because I don't want to be bitten by these same
issues again. I suggest that we learn fro
Right now the complete jsr-77 object name for each component is
determined when the module/application is "deployed" or turned into a
configuration. I don't think this is really the most useful behavior.
I think that the domain and server components of the object name should
be determined by
Geir Magnusson Jr. wrote:
On Nov 7, 2004, at 1:21 PM, Bruce Snyder wrote:
Per these disagreements, I think that we should address them before we
move on simply because I don't want to be bitten by these same issues
again. I suggest that we learn from this issue and set forth some
guidelines for
On Nov 7, 2004, at 1:21 PM, Bruce Snyder wrote:
Per these disagreements, I think that we should address them before we
move on simply because I don't want to be bitten by these same issues
again. I suggest that we learn from this issue and set forth some
guidelines for the future.
As for the di
Aaron Mulder wrote:
Can you state your current opinion and reasoning? I think that's
more valuable than a vote, at this stage. I know I'd like to have a
broader discussion to try to agree on the best solution, or at least the
best specific options to propose for a vote. For example, I th
Well, this raises an interesting issue. The page you've referred
to is 100% obsolete, because Geronimo is no longer in the incubator. You
(or your friend) must have gotten there from Google or a bookmark or
soemthing, because Geronimo isn't even in the navigation menu to the left
of that
On Sun, 7 Nov 2004, Bruce Snyder wrote:
> Per these disagreements, I think that we should address them before we
> move on simply because I don't want to be bitten by these same issues
> again. I suggest that we learn from this issue and set forth some
> guidelines for the future.
>
> As for th
Bruce,
Can you state your current opinion and reasoning? I think that's
more valuable than a vote, at this stage. I know I'd like to have a
broader discussion to try to agree on the best solution, or at least the
best specific options to propose for a vote. For example, I think we've
kin
pace vobiscum!
Speaking only for myself, I think that geronimo and the people involved
are top-notch. The project and the people are too good to allow this
sort of devolution. I really think that where one feels heat seeking
light would be preferrable. And, I want to say that often I am the
Jeremy Boynes wrote:
Last Thursday, Aaron Mulder and I had a heated but healthy technical
discussion on this list about the implementation of certain features in
the new deployer. It became clear to both of us that continuing to use
email was getting unproductive and Aaron pinged me on IM to see if
Aaron Mulder wrote:
Just to reiterate, I think Jeremy is saying that using the
deployer tool for offline install is limited because it doesn't know what
GBeans the server is using for the ConfigStore and PersistentConfigList
and so on. If we instead actually start the server to do an "offline"
geronimo connector xsd refers to sun schemas
Key: GERONIMO-451
URL: http://nagoya.apache.org/jira/browse/GERONIMO-451
Project: Apache Geronimo
Type: Bug
Components: connector
Versions: 1.0-M2
Reporter: Davi
GBeans should use jsr-77 naming conventions and these names should have mostly
default components
-
Key: GERONIMO-450
URL: http://nagoya.apache.org/jira/browse/GERONIMO-450
Proje
[ http://nagoya.apache.org/jira/browse/GERONIMO-435?page=history ]
David Jencks closed GERONIMO-435:
-
Resolution: Fixed
Fix Version: 1.0-M3
Implemented. Every builder has a defaultParentId attribute. A service module
can specify "no parent
Last Thursday, Aaron Mulder and I had a heated but healthy technical
discussion on this list about the implementation of certain features in
the new deployer. It became clear to both of us that continuing to use
email was getting unproductive and Aaron pinged me on IM to see if we
could discuss the
Aaron Mulder wrote:
I've added all the M3 issues to the M3 release notes. There were
about 60 of them.
I've got a ChangeLog formatted doc of all the changes pulled directly
from SVN if you're interested. It'll first need to be filtered a bit,
but that shouldn't be too difficult.
There are 12
For some reason you have to refresh and build openejb, then go back to
building Geronimo.
> -Original Message-
> From: toby cabot [mailto:[EMAIL PROTECTED]
> Sent: Saturday, November 06, 2004 10:39 PM
> To: [EMAIL PROTECTED]
> Subject: build problem?
>
> Hi folks,
>
> Friday I could buil
On Mon, 8 Nov 2004, Gianny Damour wrote:
> +1
>
> As an aside, the new deployer can not distribute unpacked modules. Is it
> intentional?
JSR-88 doesn't support unpacked modules. If you like, we could
assume any directory is an unpacked module, JAR it, distribute the JAR,
then delete
+1
As an aside, the new deployer can not distribute unpacked modules. Is it
intentional?
Thanks,
Gianny
On 7/11/2004 4:35 AM, Aaron Mulder wrote:
I'd like to remove the current "deployer.jar" tool, remove the
command-line processing logic from the Deployer class, rename
"new-deployer.jar"
It doesn't even start, just craps out complaining that OpenORB
doesn't support the VM (Sun 1.5.0 for Linux). I put in a JIRA and a
report to OpenORB, but this is a blocker. I hate to just comment out the
whole thing, but I can't get a full build with it in there, and I think
1.5 is a tar
+1
-- Ralf
Just to reiterate, I think Jeremy is saying that using the
deployer tool for offline install is limited because it doesn't know what
GBeans the server is using for the ConfigStore and PersistentConfigList
and so on. If we instead actually start the server to do an "offline"
deployment/
To add to this, Bruce had the same problem Friday, and it was
solved through sufficient deleting of pre-downloaded files. I think it
was just ~/.maven/repository/axis, but it may have been more.
Aaron
On Sun, 7 Nov 2004, Davanum Srinivas wrote:
> check axis jars in your local maven rep
check axis jars in your local maven repo. they may be corrupted.
thanks,
dims
On Sat, 06 Nov 2004 23:15:48 -0800, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> David Jencks wrote:
>
>
> > I haven't been building axis for a while because of the following problem:
> >
> > /Users/david/geronimo/ger
[ http://nagoya.apache.org/jira/browse/GERONIMO-435?page=history ]
David Jencks reassigned GERONIMO-435:
-
Assign To: David Jencks (was: Jeremy Boynes)
> Should be able to specifiy default parent config id
> --
[ http://nagoya.apache.org/jira/browse/GERONIMO-429?page=history ]
Gianny DAMOUR closed GERONIMO-429:
--
Resolution: Fixed
Fix Version: 1.0-M3
This capability has been implemented. The optional element
enforce-foreign-key-constraints indicates
David Jencks wrote:
I haven't been building axis for a while because of the following problem:
/Users/david/geronimo/geronimo/svn/geronimo/trunk/modules/axis/target/
generated/samples/echo-jar/org/apache/ws/echosample/
EchoStruct_Helper.java:13: cannot resolve symbol
symbol : constructor TypeDe
Aaron Mulder wrote:
I'd like to remove the current "deployer.jar" tool, remove the
command-line processing logic from the Deployer class, rename
"new-deployer.jar" to "deployer.jar" and change the bootstrapper to build
the new one instead of the old one. Currently there are two so we'd hav
I haven't been building axis for a while because of the following
problem:
/Users/david/geronimo/geronimo/svn/geronimo/trunk/modules/axis/target/
generated/samples/echo-jar/org/apache/ws/echosample/
EchoStruct_Helper.java:13: cannot resolve symbol
symbol : constructor TypeDesc (java.lang.Clas
As promised Thursday, here are the details of my concerns about mixing
offline and online deployment.
My concerns on this issue stem from how we package GBeans together for
use by the kernel. Rather than handling them one-by-one, Geronimo uses
the notion of a pre-canned Configuration which contains
Hi folks,
Friday I could build OK (using an older version of HOWL) but after a
svn up today I get the failure below. Any help appreciated.
Thanks,
Toby
jar:jar:
assemble:
[copy] Copying 1 file to
/eng/home/tcabot/try/geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/lib
[copy] Co
45 matches
Mail list logo
