[jira] [Assigned] (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom reassigned GERONIMO-4350:


Assignee: (was: Dain Sundstrom)

> Connection proxying to imitate DissociatableManagedConnection can easily 
> cause problems
> ---
>
> Key: GERONIMO-4350
> URL: https://issues.apache.org/jira/browse/GERONIMO-4350
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 2.1, 2.1.4, 2.2
>Reporter: David Jencks
> Fix For: Wish List
>
>
> We have some code to imitate the DissociatableManagedConnection to avoid 
> connection leaks that proxies connections from the supplied 
> ManagedConnectionFactory: the proxy implements all the interfaces of the 
> connection, but not the class itself.  However, there's nothing stopping the 
> ConnectionFactory from casting the (now proxied) connection to the 
> implementation class it expects.
> The TxConnect project at sourceforge illustrates this approach in the 
> EisConnectionFactory.
> http://txconnect.sourceforge.net
> One possible solution would be to have a flag to turn on this proxying 
> behavior.  I don't immediately see a way to detect if the problem will occur.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] XBean 3.15 release

[Dain Sundstrom]

+1 

-dain

[jira] Created: (GERONIMO-5842) InternetAddress.parse fails on a valid address

[Dain Sundstrom (JIRA)]

InternetAddress.parse fails on a valid address
--

 Key: GERONIMO-5842
 URL: https://issues.apache.org/jira/browse/GERONIMO-5842
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Reporter: Dain Sundstrom


The InternetAddress parser is restricting the local part to not have multiple 
dots in a row.  Although this may be rfc822 compliant, email address on the 
internet can and do have multiple dot in the local part.  For example the email 
address "k..al...@enron.com" was an address at Enron and is included in the 
Enron email corpus:
 
InternetAddress.parse("k..al...@enron.com");

Exception in thread "main" javax.mail.internet.AddressException: Invalid local 
part (k..al...@enron.com,2)
at 
javax.mail.internet.AddressParser.illegalAddress(AddressParser.java:1126)
at 
javax.mail.internet.AddressParser.validateLocalPart(AddressParser.java:1287)
at 
javax.mail.internet.AddressParser.validateAddressSpec(AddressParser.java:1232)
at 
javax.mail.internet.AddressParser.validateSimpleAddress(AddressParser.java:1213)
at 
javax.mail.internet.AddressParser.parseSingleAddress(AddressParser.java:440)
at 
javax.mail.internet.AddressParser.parseAddressList(AddressParser.java:91)
at javax.mail.internet.InternetAddress.parse(InternetAddress.java:557)
at javax.mail.internet.InternetAddress.parse(InternetAddress.java:529)
at javax.mail.internet.InternetAddress.parse(InternetAddress.java:517)



-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom closed GERONIMO-4350.


Resolution: Invalid
  Assignee: David Jencks  (was: Dain Sundstrom)

The problem was in user code that was attempting to downcast a connection proxy 
to a specific implementation class which is not allowed by the JEE Connector 
specification.

> Connection proxying to imitate DissociatableManagedConnection can easily 
> cause problems
> ---
>
> Key: GERONIMO-4350
> URL: https://issues.apache.org/jira/browse/GERONIMO-4350
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 2.1, 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.1.4, 2.2
>
>
> We have some code to imitate the DissociatableManagedConnection to avoid 
> connection leaks that proxies connections from the supplied 
> ManagedConnectionFactory: the proxy implements all the interfaces of the 
> connection, but not the class itself.  However, there's nothing stopping the 
> ConnectionFactory from casting the (now proxied) connection to the 
> implementation class it expects.
> The TxConnect project at sourceforge illustrates this approach in the 
> EisConnectionFactory.
> http://txconnect.sourceforge.net
> One possible solution would be to have a flag to turn on this proxying 
> behavior.  I don't immediately see a way to detect if the problem will occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (XBEAN-111) Only register Converters with the VM when requested

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/XBEAN-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom closed XBEAN-111.


Resolution: Fixed

> Only register Converters with the VM when requested
> ---
>
> Key: XBEAN-111
> URL: https://issues.apache.org/jira/browse/XBEAN-111
> Project: XBean
>  Issue Type: Improvement
>  Components: reflect
>Affects Versions: 3.4, 3.4.1, 3.4.2
>    Reporter: Dain Sundstrom
>    Assignee: Dain Sundstrom
> Fix For: 3.4.3
>
>
> Registering the Converters in xbean-reflect with the VM PropertyEditorManager 
> creates lots of problems for some libraries and IDEs.  Since xbean-reflect 
> has a private converter registry there is no need to register the Converters 
> with the VM.  
> I have add the boolean flag registerWithVM to PropertyEditors.  When this 
> flag is set, all Converters registered with PropertyEditors are registered 
> with the VM.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[reflect] registering converters with the VM

[Dain Sundstrom]

Currently, we are registering our Converters with the VM  
PropertyEditorManager, and this is creating all sorts of problems for  
libraries like Spring and IDEs like netbeans.  Our code has it's own  
registry and only a registers them with the VM as a convenience.


As a compromise between those that like to have the Converters  
registered and those that can't, I have add the boolean flag  
registerWithVM to PropertyEditors. When this flag is set, all  
Converters registered with PropertyEditors are registered with the  
VM.  The only real issues, is if your code relies on having the  
Converters registered with the PropertyEditorManager, you will need to  
set the flag.  If this is a problem, let me know and hopefully we can  
come up with another solution for everyone.


-dain

[jira] Created: (XBEAN-111) Only register Converters with the VM when requested

[Dain Sundstrom (JIRA)]

Only register Converters with the VM when requested
---

 Key: XBEAN-111
 URL: https://issues.apache.org/jira/browse/XBEAN-111
 Project: XBean
  Issue Type: Improvement
  Components: reflect
Affects Versions: 3.4.2, 3.4.1, 3.4
Reporter: Dain Sundstrom
Assignee: Dain Sundstrom
 Fix For: 3.4.3


Registering the Converters in xbean-reflect with the VM PropertyEditorManager 
creates lots of problems for some libraries and IDEs.  Since xbean-reflect has 
a private converter registry there is no need to register the Converters with 
the VM.  

I have add the boolean flag registerWithVM to PropertyEditors.  When this flag 
is set, all Converters registered with PropertyEditors are registered with the 
VM.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4350) Connection proxying to imitate DissociatableManagedConnection can easily cause problems

[Dain Sundstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638652#action_12638652
 ] 

Dain Sundstrom commented on GERONIMO-4350:
--

I'm not sure I understand the problem.  IIRC, a spec-compliant RA is required 
to list all interfaces that are needed by calling code (so we know what to add 
to the proxy).

Anyway, if this is something we want/need to support, I can this of a few 
workarounds/solutions (listed in order of difficulty for Geronimo):

1) add a getDelegate method one of the interfaces like JDBC and JPA use
2) add a flag to turn of connection GC
3) rewrite the connection pool code to use weak references for garbage detection

Option 3 is the most reliable but a lot more work.

> Connection proxying to imitate DissociatableManagedConnection can easily 
> cause problems
> ---
>
> Key: GERONIMO-4350
> URL: https://issues.apache.org/jira/browse/GERONIMO-4350
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 2.1, 2.2
>Reporter: David Jencks
>Assignee: Dain Sundstrom
> Fix For: 2.1.4, 2.2
>
>
> We have some code to imitate the DissociatableManagedConnection to avoid 
> connection leaks that proxies connections from the supplied 
> ManagedConnectionFactory: the proxy implements all the interfaces of the 
> connection, but not the class itself.  However, there's nothing stopping the 
> ConnectionFactory from casting the (now proxied) connection to the 
> implementation class it expects.
> The TxConnect project at sourceforge illustrates this approach in the 
> EisConnectionFactory.
> http://txconnect.sourceforge.net
> One possible solution would be to have a flag to turn on this proxying 
> behavior.  I don't immediately see a way to detect if the problem will occur.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Entropy, or the heat death of the geronimo code base

[Dain Sundstrom]

On Feb 28, 2008, at 3:07 PM, David Jencks wrote:

A few years ago I read about an information based perpetual motion  
machine someone came up with.  IIRC many people studied it for quite  
a while before realizing that the flaw was an assumption that  
erasing information was free.  It turned out to require the same  
energy as apparently extracted from the machine.


By applying this "green svn" energy saving principle we have an  
unparalleled opportunity to assure that future visitors to our svn  
repo will have no way of finding the live code.


OR...

we could clean up the leftovers from completed refactoring efforts  
and releases.


LOL :)


dain:
sandbox/plugins/global-jndi (I'm pretty sure I've got this all into  
trunk)


This should be deleted.


sandbox/spring-assembly (last modified 2006)


This was an experiment of mine that started the geronimo server using  
spring instead of the geronimo kernel.  It is just cruft now and  
should be deleted.


-dain

[reflect] Object graph support

[Dain Sundstrom]

I've committed my initial work on build object graphs with xbean  
reflect.  The code works, but I need to do more testing and a few more  
features are needed.  I'm going to be on vacation for the next 10  
days, and if you all decide to do another release of xbean for the  
quick fix Guillaume suggested, please don't release this code.


Thanks,

-dain

Re: Site Broken?

[Dain Sundstrom]

Also it looks like the snippit macro isn't working on the published  
site:


Working cwiki page:
http://cwiki.apache.org/confluence/display/XB/Custom+XML

Broken site page:
http://geronimo.apache.org/xbean/custom-xml.html

Anyone have ideas on how to fix this?

-dain

On Jan 18, 2008, at 10:27 AM, Dain Sundstrom wrote:

Looks like we have been a bit lax lately about adding the releases  
to the site.  David or Alan (not sure who is carrying the ball right  
now) can you add a blurb to the site http://geronimo.apache.org/xbean/


Thanks,

-dain

Site?

[Dain Sundstrom]

Looks like we have been a bit lax lately about adding the releases to  
the site.  David or Alan (not sure who is carrying the ball right now)  
can you add a blurb to the site http://geronimo.apache.org/xbean/


Thanks,

-dain

Re: Releasing 3.3?

[Dain Sundstrom]

+1

-dain

On Jan 10, 2008, at 11:37 AM, Bruce Snyder wrote:


On Jan 10, 2008 3:40 AM, David Blevins <[EMAIL PROTECTED]> wrote:
We need a release of xbean for openejb 3.0-beta-2.  So unless  
somebody

objects, I'll cut one friday.


+1

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"

);'

Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/

Blog: http://bruceblog.org/

Re: Integrating a third-party JTA

[Dain Sundstrom]

Other then code that attempts to cast the transaction manger to  
GeronimoTransactionManager (or other Geronimo transaction interfaces)  
it shouldn't be that difficult.  The biggest issue will be if you  
want to use the Geronimo connector implementation, then you will have  
to figure out how to adapt the JTA implementation to the  
org.apache.geronimo.transaction.manager.XAWork interface.  The second  
biggest issue, will be convincing G to correctly build the JTA  
implementation which will require a GBean wrapper of some kind.


-dain

On Oct 22, 2007, at 2:29 AM, Guy Pardon wrote:


Hi,

Does anybody have any useful pointers on how to integrate a third- 
party JTA (Atomikos) into Geronimo?


Thanks,
Guy

Re: OSGifying org.apache.geronimo.specs

[Dain Sundstrom]

I'm not sure that would work for javamail.  Javamail has a strange  
discovery system where implementation of protocols, such as smtp, are  
loaded directly from the application class loader.  I believe that if  
you hide the geronimo protocol implementations, javamail won't work.


-dain

On Oct 19, 2007, at 8:19 AM, Guillaume Nodet wrote:


So the question is wether these classes are meant to be seen by other
jars or if they are only used by the javax.mail package.  If they are
to be exported, then it should be

   javax.mail*,org.apache.geronimo.mail*geronimo.osgi.export.pkg>


but if they should be of private use, we need to add the following  
property


   org.apache.geronimo.mail*geronimo.osgi.private.pkg>


I'm leaning toward the second option

On 10/19/07, Rick McGuire <[EMAIL PROTECTED]> wrote:

Guillaume,

I'm working on a project that requires the latest javamail specs, and
I've discovered that the OSGI changes have caused the org.apache.*
classes to be ommitted from the jar file, which essentially  
renders this

package inoperable.  I was able to get those classes included by
changing the  definition to "*".  Is  
that the

correct fix, or is something else more appropriate?

Rick




--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

[jira] Created: (GERONIMO-3540) Session.loadProviders(ProviderInfo info, InputStream is) doesn't seem to handle comments correctly

[Dain Sundstrom (JIRA)]

Session.loadProviders(ProviderInfo info, InputStream is) doesn't seem to handle 
comments correctly
--

 Key: GERONIMO-3540
 URL: https://issues.apache.org/jira/browse/GERONIMO-3540
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Affects Versions: 2.0.2, 2.0.1, 2.0
Reporter: Dain Sundstrom
Assignee: Rick McGuire


After reviewing the Session code, it doesn't appear that loadProviders is 
checking for comments.  I believe that if you have an entry like this:

# foo=bar; protocol=imap; type=store; class=com.sun.mail.imap.IMAPStore; 
vendor=Sun Microsystems, Inc.;

it would process the entry.  I have not tested this, so I could be wrong.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3539) Can not override providers using META-INF/javamail.providers file

[Dain Sundstrom (JIRA)]

Can not override providers using META-INF/javamail.providers file
-

 Key: GERONIMO-3539
 URL: https://issues.apache.org/jira/browse/GERONIMO-3539
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Affects Versions: 2.0.2, 2.0.1, 2.0
Reporter: Dain Sundstrom
Assignee: Rick McGuire


The Session.loadProviders(ClassLoader cl) loads provider files from:

META-INF/javamail.default.providers
${java.home}/lib/javamail.providers
META-INF/javamail.providers

but should be 

${java.home}/lib/javamail.providers
META-INF/javamail.providers
META-INF/javamail.default.providers




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Effectiveness of WADI's Design and Implementation Comforted

[Dain Sundstrom]

I agree about the annotation thing.  Would it be difficult change the  
design to have some reasonable defaults, and only use annotations (or  
xml) for overrides?


-dain

On Oct 18, 2007, at 3:49 PM, Jeff Genender wrote:


Gianni,

What you have done is very cool.  I guess my only comment is that  
what I

am reading is that the annotations force a lock to the clustering
engine, as opposed to being somewhat transparent by swapping out the
clustering manager.

Therefore, my application code needs these annotations coded as a part
of it.  In otherwords, in order for me to leverage the fine grained
capabilities of WADI, my application needs to be coded with the WADI
annotations.  Did I read that correctly?

Regardless...its pretty cool stuff.  We should talk about the
contract/interface for openejb...I look forward to working with  
you ;-)


Jeff



Gianny Damour wrote:

On 17/10/2007, at 11:53 PM, Jeff Genender wrote:




Gianny Damour wrote:


Excerpt of the conclusion:

"
The effectiveness of the design and implementation of WADI's  
distributed
session lookup engine and replication engine is further  
comforted by the

observed average response times and scalability characteristics.
For the considered scenarios, WADI performs better than Terracotta,
which is not really surprising as...



If I may comment here...Without fine-grained clustering  
capabilities, I

have a hard time believing that WADI can outperform Terracotta.
Especially with large objects...WADI would push over the entire  
object
each time, where Terracotta would only ship the changed members.   
If you
are going to publish the numbers you did, you probably should  
explain

what is getting pushed across.


Hi,

I believe you simply skimmed through what I have been writing:  
firstly,

I did provide a description of the state stored in session. Secondly,
your comment about large objects and the inadequacy of WADI's  
design to
handle them is clearly and explicitly discussed in the  second  
paragraph
of the conclusion. As redundancy of information is not much of a  
problem

for theoretical clustering discussions, I am reiterating: WADI does
provide a fine grained replication mechanism, which is able to track
field updates or method executions and replay them against  
replicas. If
you are interested by this kind of stuff, then please feel free to  
have

a look to this WIKI page -
http://docs.codehaus.org/display/WADI/5.+Delta+Session+Replication.

At this stage, the delta replication stuff is under performing and
resource intensive: to give you an idea, its average response time is
6.10ms for the third test scenario (average response time for default
replication mechanism is 4.77ms for WADI and 6.36ms for Terracotta).
Once again, as a preliminary comment to Ari's response, this is a
scenario with HTTP session stickiness on. After this week-end, the
performance for fine-grained replication should improve  
significantly. I
intend to: get ride of native reflection; index constructor, field  
and

methods description for really fast packaging on wire and resolution
when reading back from a byte stream; and re-use reflective invokers
(CGLIB FastMethod/Constructor and ASM customed field updaters).

FWIW, I do not see support of large objects as crucial as you for Web
solutions. Even if I spent a couple of months working on wadi-aop to
provide this feature, it was more with the ultimate goal to  
leverage it
for efficient distributed caching than HTTP session replication. I  
truly
believe that large scale Web solutions requiring HA have to be  
designed

with this constraint in mind; with this constraint in mind, keeping
session size small sounds reasonable.



"

If people are interested by clustering development, then please  
respond
as I will resume some Geronimo clustering work and could really  
use a

hand.



I am in the midst of getting OpenEJB clusterable.  I would be  
happy to

combine forces and get clustering finished up for G ;-)


Great! Will post back to the dev@ list as soon as I resume Geronimo
clustering work.

Thanks,
Gianny






Thanks,
Gianny

Re: Effectiveness of WADI's Design and Implementation Comforted

[Dain Sundstrom]

I'd also like to see a sticky test as most of the clusters I have  
worked with use a high-end hardware load balancer (although I do find  
this test very interesting).  I'd also like to see the test use a  
larger and mutating session.  One of the things that will effect  
latency is the time (and effort) it takes to move the session data.   
With people sticking large caches of detached JPA objects in sessions  
now days, I'd like to know how that effects my application performance.


Finally, how about a wadi vs tribes on Tomcat?

BTW you should talk to Jason about testing this on GBuild, so you can  
test in a true distributed state.


-dain

On Oct 18, 2007, at 12:02 AM, ikarzali wrote:





jgenender wrote:




Excerpt of the conclusion:

"
The effectiveness of the design and implementation of WADI's  
distributed
session lookup engine and replication engine is further comforted  
by the

observed average response times and scalability characteristics.
For the considered scenarios, WADI performs better than Terracotta,
which is not really surprising as...



If I may comment here...Without fine-grained clustering  
capabilities, I

have a hard time believing that WADI can outperform Terracotta.
Especially with large objects...WADI would push over the entire  
object
each time, where Terracotta would only ship the changed members.   
If you

are going to publish the numbers you did, you probably should explain
what is getting pushed across.



Interesting test of Terracotta.  I wouldn't trust any test that  
pegs the CPU

at 100%.  May I suggest the following potential changes:

1. Running Jetty, Grinder, and Terracotta on a single laptop should  
change.
Run Terracotta on its own server.  It will run faster even though  
it won't

be over loopback.

2. Run sticky and see what happens.  See, the test is not testing  
the same
thing with WADI and Terracotta.  With WADI, the clustering  
implementation is
configured to keep data on  a finite number of nodes.  With  
Terracotta, you
have a consistent clustered view of sessions.  Since you are round- 
robin,
with Terracotta every node is holding a reference to every session  
and as
the sessions change, all Jetty nodes are updated with the change.   
So, round
robin WITH WADI replication off is actually pretty much cheating  
because TC
has the sessions in all nodes and WADI has them in one.  Run sticky  
sessions
in your load balancer.  Then Terracotta will have the session in  
one node
just like WADI.  _Then_ you will have apples-to-apples and maybe  
find TC

latency to be lower and throughput higher.

I would be happy to help explain more but this use of WADI and  
Terracotta
seem like you are getting opposite behaviors out of the products  
(full n-way
replication with no SPoF under Terracotta versus zero replication  
under

WADI) and a different test will more accurately reflect the relative
performance of the systems.

--Ari

--
View this message in context: http://www.nabble.com/Effectiveness- 
of-WADI%27s-Design-and-Implementation-Comforted- 
tf4640401s134.html#a13269164
Sent from the Apache Geronimo - Dev mailing list archive at  
Nabble.com.

Re: [VOTE] Release XBean 3.2

[Dain Sundstrom]

+1

-dain

On Oct 1, 2007, at 8:10 AM, Guillaume Nodet wrote:


Please vote on releasing xbean 3.2.
Binaries / maven repo is available at:
   http://people.apache.org/~gnodet/xbean-3.2/
Svn source tag is available at:
   http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.2/

It includes David Jencks last minute fix too.

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: KEYS ?

[Dain Sundstrom]

I'm not sure, but it may be mentioned in old binaries as the location  
for verifying the signatures.  I could be completely wrong... I just  
have a memory of some external references.  If you do move the file,  
I'd definitely search the website for references.


-dain

On Jul 27, 2007, at 12:35 PM, Jason Dillon wrote:


What external references are you referring to?

I believe that it does have symlink support, though I hardly ever  
use it.


--jason


On Jul 27, 2007, at 12:29 PM, Dain Sundstrom wrote:

I think there are external references to this file, but I'm not  
sure how we should deal with them.  Does svn have symlink support?


-dain

On Jul 26, 2007, at 3:52 PM, Jason Dillon wrote:

Should keys move up to a peer to the STATUS file too?  Seems  
these are project global, not specific to the server bits...


--jason

Re: What to do with legacy EJB 2.1 code in DayTrader?

[Dain Sundstrom]

I'd like to see the 2.1 code kept around so we can compare base EJB  
performance against other servers.  There is going to be legacy code  
for a long time and this tool is our only way to see how legacy code  
performs on our server.


-dain

On Jul 25, 2007, at 9:56 AM, Christopher Blythe wrote:


All,

Given Geronimo 2.0 and DayTrader 2.0's focus on Java EE 5, I was  
wondering if it made sense to remove the old EJB 2.1 code? To be  
quite honest, I am torn. One one side, it would be nice to have  
both the EJB 2.1 and 3.0 impls at the same time for comparison  
purposes. However, keeping the old stuff around seems to hide the  
fact that 3.0 is supposed to be easier to work with and develop.


Here are some options along with my own arguments for each...

1) Remove the old EJB 2.1 modes and make DayTrader 2.0 EJB 3 only
- highlights the advantages of EJB 3.0 (less DDs, etc.)
- makes the packaging and various runtime modes less confusing
- can use the DayTrader 1.2 code for comparisons between EJB  
2.1 and 3.0
- EJB 2.1 mode never worked under load to begin with due to  
consistency issues


2) Leave 2.1 code in there for now and phase out in a DayTrader 2.X
- comparisons can be done using a single ear
- DT 2.x could be spun up immediately

Now that I think about it, I think I'm swaying more towards option  
1. However, given the time constraints to get 2.0 out  the door,  
I'm not sure if 1 is realistic.


Thoughts?

Thanks...

Chris



--
"I say never be complete, I say stop being perfect, I say let...  
lets evolve, let the chips fall where they may." - Tyler Durden

Re: KEYS ?

[Dain Sundstrom]

I think there are external references to this file, but I'm not sure  
how we should deal with them.  Does svn have symlink support?


-dain

On Jul 26, 2007, at 3:52 PM, Jason Dillon wrote:

Should keys move up to a peer to the STATUS file too?  Seems these  
are project global, not specific to the server bits...


--jason

Re: Transaction and Connector jars untied from g. kernel

[Dain Sundstrom]

Sweet!

Thanks,

-dain

On Jul 24, 2007, at 6:00 PM, David Jencks wrote:


see GERONIMO-3344.

Following years of urging from activemq/jencks/servicemix and more  
recent urging from openejb I finally split off the tx and connector  
modules into bits that implement the functionality w/o geronimo  
fluff and geronimo integration jars.


The functional bits are now under components/txmanager/trunk.  I  
have server/trunk compiling and appearing to work on my local machine.


If no one objects I'll commit my local changes to trunk later  
tonight so g 2.1-SNAPSHOT will be using the new jars.


new jars have groupId org.apache.geronimo.components, and  
artifactIds geronimo-transaction and geronimo-connector, and  
version 2.0-SNAPSHOT.


I'd really appreciate a review of the dir structure and poms from  
e.g. jdillon since I suspect a better structure may be possible.   
There is a dependency on the genesis 1.2-SNAPSHOT pom, this also is  
in g. trunk.


if all goes well perhaps we can release the new jars in a day or  
two and then openejb can release without a dependency on geronimo  
server.


thanks
david jencks

Re: OpenEJB for trunk

[Dain Sundstrom]

Geronimo should exclude these dependencies when declaring a  
dependency on OpenEJB jars.


-dain

On Jul 24, 2007, at 8:36 AM, Anita Kulshreshtha wrote:


  We need OpenEJB that uses 2.1-SNAPSHOT version Of Geronimo. I am
seeing this in offline build:

Path to dependency:
  1) org.apache.geronimo.modules:geronimo-axis:jar:2.1-SNAPSHOT
  2) org.apache.openejb:openejb-axis:jar:3.0.0-SNAPSHOT
  3) org.apache.openejb:openejb-core:jar:3.0.0-SNAPSHOT
  4)
org.apache.geronimo.modules:geronimo-transaction:jar:2.0-SNAPSHOT

Thanks
Anita




__ 
__
Get the Yahoo! toolbar and be alerted to new email wherever you're  
surfing.

http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

Re: Can Swizzle-Stream be removed?

[Dain Sundstrom]

To summarize from the discussion on the OpenEJB list, the answer is  
no.  This jar is and the classes listed below are most definitely  
used.  Even more importantly to Geronimo, they are a critical part of  
the OpenEJB/Geronimo integration.


-dain

On Jul 21, 2007, at 12:55 PM, Ted Kirby wrote:


Swizzle-Stream appears to be used in only two classes in openejb:

1. org.apache.openejb.assembler.classic.JndiBuilder

  It is used in: public static class TemplatedStrategy, but this
class does not appear to be used.

2. org.apache.openejb.config.InitEjbDeployments

 This class is only used in /openejb-core/container/openejb-core/ 
src/test,

which appears to be unit tests, but not part of any shipped server.

Some server footprint could be saved here, but since the jar is only
43 KB, it may not be worth the effort...

Ted Kirby

Re: Should we cancel 1.2?

[Dain Sundstrom]

FWIU, it is a problem with Geronimo connection pooling not OpenEJB,  
but Matt can't find the issue and he thinks instrumenting OpenEJB is  
the way to find it.


-dain

On Jul 16, 2007, at 7:17 PM, Donald Woods wrote:

Agree and if the OpenEJB(?) problem is ever fixed, then we can spin  
a 1.2.1 release...



-Donald

Jason Dillon wrote:
What were the bugs that were to be "quickly fixed"?  I forget its  
been so long.

Why not just push it out asis?
--jason
On Jul 16, 2007, at 9:53 AM, Dain Sundstrom wrote:
1.2 has been sitting in a branch for well over 6 months now.   
Originally, it was going to be delayed so some bugs could be  
"quickly fixed", but it doesn't look like that is ever going to  
happen.  I'm not really interested in being the manager for this  
release anymore, but if there is good interest in getting this  
released in, say, the next two weeks, I'm willing to continue  
on.  Otherwise, someone else can take over.


So, does anyone care about releasing 1.2?

-dain

Re: Should we cancel 1.2?

[Dain Sundstrom]

It was some connector thing Matt found.  Matt can you fill Jason in  
on the details?


-dain

On Jul 16, 2007, at 2:02 PM, Jason Dillon wrote:

What were the bugs that were to be "quickly fixed"?  I forget its  
been so long.


Why not just push it out asis?

--jason


On Jul 16, 2007, at 9:53 AM, Dain Sundstrom wrote:

1.2 has been sitting in a branch for well over 6 months now.   
Originally, it was going to be delayed so some bugs could be  
"quickly fixed", but it doesn't look like that is ever going to  
happen.  I'm not really interested in being the manager for this  
release anymore, but if there is good interest in getting this  
released in, say, the next two weeks, I'm willing to continue on.   
Otherwise, someone else can take over.


So, does anyone care about releasing 1.2?

-dain

Should we cancel 1.2?

[Dain Sundstrom]

1.2 has been sitting in a branch for well over 6 months now.   
Originally, it was going to be delayed so some bugs could be "quickly  
fixed", but it doesn't look like that is ever going to happen.  I'm  
not really interested in being the manager for this release anymore,  
but if there is good interest in getting this released in, say, the  
next two weeks, I'm willing to continue on.  Otherwise, someone else  
can take over.


So, does anyone care about releasing 1.2?

-dain

[jira] Assigned: (GERONIMO-3267) Naming lookup fails. Reported error for a different name than requested

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom reassigned GERONIMO-3267:


Assignee: Matt Hogstrom  (was: Dain Sundstrom)

I believe David Jencks committed a fix for this earlier today.  Please verify.

> Naming lookup fails.  Reported error for a different name than requested
> 
>
> Key: GERONIMO-3267
> URL: https://issues.apache.org/jira/browse/GERONIMO-3267
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
> Environment: All
>Reporter: Matt Hogstrom
>Assignee: Matt Hogstrom
> Fix For: 2.0-M7
>
>
> DayTrader 1.2 deploy's correctly on 2.0 but when an attempt to execute a 
> SessionBean is tried a JNDI lookup fails.  Here is the code from 
> TradeBean.java
>InitialContext ic = new 
> InitialContext();
>*this is line 1041  --->*  qConnFactory = (ConnectionFactory) 
> ic.lookup("*java:comp/env/jms/QueueConnectionFactory*");
> {panel:title=Name Not Found Exception| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE} 
> The lookup fails with a name not found exception.  What is odd is that the 
> exception says:
> javax.naming.NameNotFoundException: Name 
> "*java:openejb/Resource/jms/TradeBrokerQCF*" not found.
> at 
> org.apache.openejb.core.ivm.naming.IvmContext.federate(IvmContext.java:172)
> at 
> org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:129)
> at 
> org.apache.openejb.core.ivm.naming.IntraVmJndiReference.getObject(IntraVmJndiReference.java:38)
> at 
> org.apache.openejb.core.ivm.naming.Reference.getContent(Reference.java:40)
> at 
> org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:61)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:112)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597)
> at javax.naming.InitialContext.lookup(InitialContext.java:363)
> *at 
> org.apache.geronimo.samples.daytrader.ejb.TradeBean.ejbCreate(TradeBean.java:1041)*
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at 
> org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:146)
> at 
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:129)
> at 
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
> at 
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:177)
> at 
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:156)
> at 
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:211)
> at 
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:65)
> at 
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:230)
> at 
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> at $Proxy25.resetTrade(Unknown Source)
> at 
> org.apache.geronimo.samples.daytrader.TradeAction.resetTrade(TradeAction.java:510)
> at 
> org.apache.geronimo.samples.daytrader.web.TradeConfigServlet.doResetTrade(TradeConfigServlet.java:73)
> at 
> org.apache.geronimo.samples.daytrader.web.TradeConfigServlet.service(TradeConfigServlet.java:362)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChai

Re: svn commit: r551608 - in /geronimo/server/trunk: assemblies/geronimo-boilerplate-minimal/src/main/resources/bin/ maven-plugins/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/

[Dain Sundstrom]

On Jun 28, 2007, at 6:52 PM, Kevan Miller wrote:



On Jun 28, 2007, at 5:54 PM, David Jencks wrote:

This looks to me like a dreadful approach.  Did you try including  
the property in defaultPersistenceUnitProperties in the  
persistence builder config


No. I didn't find the existing properties. Did try setting a  
property in OpenEJB, which didn't work. I'll give this a try. More  
dreadful, IMO, is using the flag to *avoid* the problem. Best is  
for someone familiar with JPA/CMP to actually investigate and fix  
the underlying problem. I found the cause of the problem and fixed  
it the best I could. Which doesn't seem that "dreadful" to me...


My guess is that OpenJPA switched to the constraint based update  
model which uses the database constraints to determine the update  
order.  If the algorithm isn't order preserving (update order should  
be the default), it could introduce new problems.  Update order is a  
fine default until the constraint based code gets exercised more.


-dain

Re: Transaction manager now tied to ejb?

[Dain Sundstrom]

Awesome.  Can we do the same thing in 1.2?

-dain

On Jun 29, 2007, at 6:16 PM, David Jencks wrote:

This should be fixed in rev 552073.  Let me know if there are more  
problems.


thanks
david jencks

On Jun 29, 2007, at 11:18 AM, David Jencks wrote:

This is an easy fix, thanks for noticing the problem... just need  
a little more testing before I commit...


thanks
david jencks

On Jun 28, 2007, at 6:03 PM, Dain Sundstrom wrote:

It appears that the geronimo transaction manager is now tied  
directly to ejb :(  The TransactionManagerImpl class has the  
following code:


public void setEntityManager(String persistenceUnit, Object  
entityManager) {
Object oldEntityManager = entityManagers.put 
(persistenceUnit, entityManager);

if (oldEntityManager != null) {
throw new EJBException("EntityManager " +  
oldEntityManager + " for persistenceUnit " + persistenceUnit + "  
already associated with this transaction " + xid);

}
}

This makes it very difficult for me to use the tm manager in  
light-weight environments. Can we remove all the JPA and EJB  
related stuff from the TransactionManager classes (and module).   
I was able to implement all of the JPA required functionality in  
OpenEJB without needing to modify the transaction manager.


In the mean time I'll drop back to using the 1.x transaction  
manager.


-dain

Transaction manager now tied to ejb?

[Dain Sundstrom]

It appears that the geronimo transaction manager is now tied directly  
to ejb :(  The TransactionManagerImpl class has the following code:


public void setEntityManager(String persistenceUnit, Object  
entityManager) {
Object oldEntityManager = entityManagers.put 
(persistenceUnit, entityManager);

if (oldEntityManager != null) {
throw new EJBException("EntityManager " +  
oldEntityManager + " for persistenceUnit " + persistenceUnit + "  
already associated with this transaction " + xid);

}
}

This makes it very difficult for me to use the tm manager in light- 
weight environments. Can we remove all the JPA and EJB related stuff  
from the TransactionManager classes (and module).  I was able to  
implement all of the JPA required functionality in OpenEJB without  
needing to modify the transaction manager.


In the mean time I'll drop back to using the 1.x transaction manager.

-dain

Re: Problem in org.apache.geronimo.system.jmx.RealMBeanServerReference

[Dain Sundstrom]

This constructor is for the case when you know the agent id.  There  
used to be a case where we created an MBeanServer and then referenced  
it later.  In that case, we knew the agent id, so to guarantee that  
we got the same mbean server, I wrote this code.


I'm not sure it is used anymore.  In any case, you could add a no arg  
constructor that finds the mbean server as you have coded.


-dain

On Jun 27, 2007, at 5:05 AM, Vamsavardhana Reddy wrote:


I see the following constructor:

public RealMBeanServerReference(String mbeanServerId) throws  
MBeanServerNotFound {
ArrayList servers = MBeanServerFactory.findMBeanServer 
(mbeanServerId);

if ( servers.size() == 0) {
mbeanServer = MBeanServerFactory.createMBeanServer 
("geronimo");

} else if (servers.size() > 1) {
throw new MBeanServerNotFound(servers.size() + "  
MBeanServers were found with the agent id " + mbeanServerId);

} else {
mbeanServer = (MBeanServer) servers.get(0);
}
}

I guess the intention of this code is to use a single MBeanServer  
for all geronimo MBeans and the default domain for that MBeanServer  
be "geronimo".  MBeanServerFactory.createMBeanServer() takes domain  
as parameter.  Whereas MBeanServerFactory.findMBeanServer() takes  
AgentId.  There is no (easy) way to create an MBeanServer with a  
predefined agentId.  Does this mean mbeanServerId parameter is  
redundant?  Should this code be searching for an MBeanServer with  
default domain "geronimo" and creating one if there is none?  In  
this case, the code should look something like...


   public RealMBeanServerReference(String mbeanServerId) throws  
MBeanServerNotFound {

ArrayList servers = MBeanServerFactory.findMBeanServer(null);
for(int i = 0; i < servers.size(); ++i) {
if("geronimo".equals(((MBeanServer) servers.get 
(i)).getDefaultDomain()))

mbeanServer = (MBeanServer) servers.get(i);
}
if(mbeanServer == null) mbeanServer =  
MBeanServerFactory.createMBeanServer("geronimo");

}

I am also noticing that if I create a new JMX agent by specifiying  
the system property com.sun.management.jmxremote.port, geronimo  
hooks up to the MBeanServer created with default domain name  
"DefaultDomain" instead of creating a new one for itself with  
default domain "geronimo".


Vamsi

Re: [ANNOUNCE] Welcome Tim McConnell as our newest committer

[Dain Sundstrom]

Congratulations! You have definitely earned it.

-dain

On Jun 21, 2007, at 3:36 PM, David Blevins wrote:


All,

The Geronimo PMC is pleased to announce that Tim McConnell has  
recently accepted our invitation to become an Apache Geronimo  
committer.  Tim has done some great work in 2.0 with regards to  
annotation processing and was a definite asset in completing the  
JavaEE 5 functionality.


We're thrilled to hand him a committer hat and look forward to his  
continued contributions to the project and to other contributors  
who wish to walk the same road he did.


Welcome aboard, Tim!

-David

Re: [VOTE] 2.0-M6 (rc3)

[Dain Sundstrom]

+1

-dain

On Jun 11, 2007, at 7:59 PM, Matt Hogstrom wrote:

I think I've narrowed the problem on the rebuild.  When building  
from the top-level it seems we pick up more cars than we want.  If  
I build local in the assemblies dir then things seem to be scoped  
correctly.  Something odd with Maven and / or how were using it.


The binaries are uploading now so please take a peek.

http://people.apache.org/~hogstrom/2.0-M6-rc3

Vote concludes on Thursday June 14th at 2300 hours.

[ ] +1 release
[ ] 0 abstain
[ ] -1 Don't ship...provide reason

Re: [VOTE] Release of javamail 1.4 specs and javamail 1.4 providers

[Dain Sundstrom]

+1

-dain

On Jun 12, 2007, at 8:03 AM, Rick McGuire wrote:

Please review the javamail specifications located at http:// 
people.apache.org/~prasad/specs_rc1/


The files in question are geronimo-javamail_1.4_spec-1.0.tar.gz  
, which is the api spec jar and  
geronimo-javamail_1.4-1.1.tar.gz , which is the  
javamail provider implementations and the merged mail jar.  The  
provider jar has a dependency on the javamail spec jar.  The merged  
mail jar is used by Geronimo 2.0 for the javamail implementation.


Voting concludes on Friday, June 15th at 1100 ET

Rick

Re: [VOTE] Release specs for El, J2EE Management, JSP, WS-Metadata

[Dain Sundstrom]

On Jun 11, 2007, at 10:32 AM, David Jencks wrote:


el: + 0.1 missing scm section in pom.xml
j2ee-management: +0.1 missing scm section in pom.xml.  Is the spec  
still called "j2ee management"?
jsp-2.1:  -1 unless the comments in the following files are not  
from sun or there is a written licensing trail showing we can  
redistribute them:

---  javax/servlet/jsp/resources/jspxml.xsd
---  javax/servlet/jsp/resources/web-jsptaglibrary_1_1.dtd
---  javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd

I also wonder if it's intentional that there are apparent  
duplications:

 javax/servlet/jsp/resources/jsp_2_1.xsd
 javax/servlet/jsp/resources/web-jsptaglibrary_2_1.xsd
 javax/servlet/resources/jsp_2_1.xsd
 javax/servlet/resources/web-jsptaglibrary_2_1.xsd


If memory serves me,  Tomcat looked for these files in one location  
and Jetty looked in the other.  If we decide to leave the files, we  
should leave both copies since there is likely to be code that  
depends on both locations.


-dain

Re: [VOTE] Release specs for El, J2EE Management, JSP, WS-Metadata

[Dain Sundstrom]

+1

-dain

On Jun 8, 2007, at 8:06 PM, Prasad Kashyap wrote:


Please review the specifications located at
http://people.apache.org/~prasad/specs_rc1/

We are voting these in a block.  Failures will be removed from the
block and others will proceed forward.

Voting concludes on Monday, June 11th at 2300 ET.

Cheers
Prasad

Re: [VOTE] Release specs for Activation, JACC, Deployment, Servlet and StAX

[Dain Sundstrom]

+1

-dain

On Jun 8, 2007, at 2:43 PM, Matt Hogstrom wrote:

Please review the specifications located at http:// 
people.apache.org/~hogstrom/specs-rc1/


We are voting these in a block.  Failures will be removed from the  
block and others will proceed forward.


Voting concludes on Monday, June 11th at 1800 ET.

Thanks

Re: Releasing the current SPECs

[Dain Sundstrom]

Please double check that all dependencies of the specs are marked as  
provided before spinning the release.


-dain

On Jun 7, 2007, at 8:36 AM, Matt Hogstrom wrote:

I am putting together a list of specs that need to be released.  I  
am planning on taking the current SNAPSHOTs in Geronimo and putting  
them up for individual votes.  Not to worry, if they change we can  
release another one but this will reduce the clutter and help out  
some o f our brethern that are also trying to release.


Comments welcome.

Re: GBeanInfoBuilder [was Re: svn commit: r499201 - in /geronimo/server/trunk/modules/geronimo-kernel/src: main/java/org/apache/geronimo/gbean/ main/java/org/apache/geronimo/gbean/runtime/ test/java/o

[Dain Sundstrom]

Sounds good to me.  BTW, if you don't want the get/set methods to  
show up in a JMX console, just don't add them to the  MBeanInfo.


-dain

On Jun 5, 2007, at 5:23 PM, Anita Kulshreshtha wrote:


Dain,
   I was able to observe this problem on webconsole. I would like to
reapply this patch with following modifications:
1. Leave addOperation(String ..) ASIS, i.e., getters/setters must be
added as operation explicitly to be able to invoke them as operation.
2. Fix tests to demonstrate this behavior.
   Any objections?

Thanks
Anita


--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:


   We are not doing this at present. Please see:

http://www.nabble.com/Re%3A-svn-commit%3A-r499201---in--geronimo- 
server-trunk-modules-geronimo-kernel-src%3A-main-java-org-apache- 
geronimo-gbean--main-java-org-apache-geronimo-gbean-runtime--test- 
java-org-apache-geronimo-gbean--p8769582.html

   The above output is for rev 502653 without my patch. The
getValue()
method is a valid getter.

Thanks
Anita

--- Dain Sundstrom <[EMAIL PROTECTED]> wrote:


All methods regardless of if they are valid getters or setters

should


be exposed via the invoke method (using an operation info).

-dain





__ 
__
Looking for a deal? Find great prices on flights and hotels with  
Yahoo! FareChase.

http://farechase.yahoo.com/

Re: RELEASE NOTES 2.0-M6

[Dain Sundstrom]

IIRC it is caused by people marking a new issues as "affects" 2.0-M6  
which is logically incorrect because an issue fixed in 2.0-M6 could  
not affect that release (since it is fixed).  People commonly make  
this mistake because the believe that 2.0-M6-SNAPSHOT is the same  
thing as 2.0-M6 so they incorrectly believe that an issue is  
affecting 2.0-M6.


-dain

On Jun 4, 2007, at 2:10 PM, Hernan Cunico wrote:


Good question ;-)
There is a link in JIRA that creates this list of issues  
automatically (aka Release Notes). We should definitively show all  
the issues we already fixed ( a Bug fixes section maybe), and  
agree, Known issues and limitations should show exactly that,  
things we have not addressed yet.


I think there was some discussion about this some time ago, I'll  
see if I can find it.


Cheers!
Hernan

Prasad Kashyap wrote:

Wait a min. All those JIRAs in the release notes are in CLOSED/FIXED
state. But why are they under the "Known Issues and Limitations"
section ?
In any case, GERONIMO-3138 has been reopened. It should now be taken
off the list
https://issues.apache.org/jira/browse/GERONIMO-3138
Cheers
Prasad
On 6/4/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
I believe Anita's multiple instances work is now closed and has  
gone in M6.

http://issues.apache.org/jira/browse/GERONIMO-3011

I'm editing the release notes to affect this change.

Cheers
Prasad

On 6/1/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> Alright, here is the template for the release notes.
>
> Need your input on the significant changes for this milestone  
release. Here is the link.

>
> http://cwiki.apache.org/GMOxDOC20/release-notes-20-m6txt.html
>
> Pls chime in with the updates.
>
> Cheers!
> Hernan
>

[jira] Updated: (GERONIMO-2950) Build test failure in geronimo-naming

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom updated GERONIMO-2950:
-

  Component/s: naming
 Priority: Minor  (was: Major)
Affects Version/s: 2.0-M6
Fix Version/s: 2.0-M7
 Assignee: Kevan Miller  (was: Dain Sundstrom)

> Build test failure in geronimo-naming
> -
>
> Key: GERONIMO-2950
> URL: https://issues.apache.org/jira/browse/GERONIMO-2950
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: naming
>Affects Versions: 2.0-M6
>Reporter: Kevan Miller
>Assignee: Kevan Miller
>Priority: Minor
> Fix For: 2.0-M7
>
> Attachments: GERONIMO-2950.patch
>
>
> server/trunk builds are failing in geronimo-naming junit tests. 
> Running org.apache.geronimo.gjndi.JavaCompContextTest
> lookup(String) milliseconds: 432
> Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.461 sec <<< 
> FAILURE!  
> ---
> Test set: org.apache.geronimo.gjndi.JavaCompContextTest
> ---
> Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.462 sec <<< 
> FAILURE!
> testSchemeLookup(org.apache.geronimo.gjndi.JavaCompContextTest)  Time 
> elapsed: 0.006 sec  <<< ERROR!
> javax.naming.NotContextException: java:comp/env/hello
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:161)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597)
> at 
> org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:44)
> at 
> org.apache.geronimo.gjndi.JavaCompContextTest.testSchemeLookup(JavaCompContextTest.java:86)
>   
> I'm going to remove the test and have Dain fix...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-2950) Build test failure in geronimo-naming

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom updated GERONIMO-2950:
-

Attachment: GERONIMO-2950.patch

Problem is fixed in xbean-naming 3.1-SNAPSHOT, but I don't think we should 
change versions until the next G version is shipped as the fix could cause 
unintended regressions.

> Build test failure in geronimo-naming
> -
>
> Key: GERONIMO-2950
> URL: https://issues.apache.org/jira/browse/GERONIMO-2950
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Kevan Miller
>    Assignee: Dain Sundstrom
> Attachments: GERONIMO-2950.patch
>
>
> server/trunk builds are failing in geronimo-naming junit tests. 
> Running org.apache.geronimo.gjndi.JavaCompContextTest
> lookup(String) milliseconds: 432
> Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.461 sec <<< 
> FAILURE!  
> ---
> Test set: org.apache.geronimo.gjndi.JavaCompContextTest
> ---
> Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.462 sec <<< 
> FAILURE!
> testSchemeLookup(org.apache.geronimo.gjndi.JavaCompContextTest)  Time 
> elapsed: 0.006 sec  <<< ERROR!
> javax.naming.NotContextException: java:comp/env/hello
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:161)
> at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597)
> at 
> org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:44)
> at 
> org.apache.geronimo.gjndi.JavaCompContextTest.testSchemeLookup(JavaCompContextTest.java:86)
>   
> I'm going to remove the test and have Dain fix...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-2768) geronimo-j2ee-management_1.1_spec is still using geronimo-ejb_2.1_spec instead of new ejb_3.0_spec

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom closed GERONIMO-2768.


   Resolution: Fixed
Fix Version/s: (was: 2.0-M5)
   2.0-M6

> geronimo-j2ee-management_1.1_spec is still using geronimo-ejb_2.1_spec 
> instead of new ejb_3.0_spec
> --
>
> Key: GERONIMO-2768
> URL: https://issues.apache.org/jira/browse/GERONIMO-2768
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: specs
>Affects Versions: 2.0-M2
>Reporter: Donald Woods
>Assignee: Dain Sundstrom
>Priority: Minor
> Fix For: 2.0-M6
>
> Attachments: G2768.patch
>
>
> geronimo/spces/trunk/geronimo-j2ee-management_1.1_spec is still using 
> geronimo-ejb_2.1_spec-1.1 instead of the new geronimo-ejb_3.0_spec-1.0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: tarball issues

[Dain Sundstrom]

It is a bug that Maven inherited from Ant 1.6

  http://issues.apache.org/bugzilla/show_bug.cgi?id=28776

I'm not sure there is much we can do other then re-tar/checksum/sign  
the archives, and that will take convincing the release manager it is  
worth the extra effort.


-dain

On May 27, 2007, at 3:01 PM, David Jencks wrote:

I think this is not a problem but some kind of artifact from either  
ant or maven's tgz algorithm.  I've certainly been seeing it for  
ages with no apparent ill effects.


thanks
david jencks

On May 27, 2007, at 11:18 AM, Don Hill wrote:


Hi,

There seems to be a minor issue when extracting the geronimo- 
tomcat6-jee5-2.0-SNAPSHOT.tar.gz, i am building this locally and  
running SuSE SLED. Here is the issue I have encountered.


extracting the tar with :
tar -vzxf  ./assemblies/geronimo-tomcat6-jee5/target/geronimo- 
tomcat6-jee5-2.0-SNAPSHOT-bin.tar.gz I get the following.


geronimo-tomcat6-jee5-2.0-SNAPSHOT/schema/geronimo-tomcat-1.2.xsd
geronimo-tomcat6-jee5-2.0-SNAPSHOT /schema/geronimo-tomcat- 
config-1.0.xsd
geronimo-tomcat6-jee5-2.0-SNAPSHOT/var/config/jsr88-configurer- 
config.xml

geronimo-tomcat6-jee5-2.0-SNAPSHOT/var/config/config.xml
geronimo-tomcat6-jee5-2.0-SNAPSHOT/var/config/offline- deployer- 
config.xml

tar: Archive contains obsolescent base-64 headers
tar: A lone zero block at 159618

then if I run the file command as:

file  ./assemblies/geronimo-tomcat6-jee5/target/geronimo-tomcat6- 
jee5-2.0-SNAPSHOT-bin.tar.gz
./assemblies/geronimo-tomcat6-jee5/target/geronimo-tomcat6- 
jee5-2.0-SNAPSHOT-bin.tar.gz: gzip compressed data, from MS-DOS



Not really sure about the ms-dos part but just wanted to pass it  
on, btw I am not on 64bit hardware


Don

Re: [VOTE] Release XBean 3.0.1

[Dain Sundstrom]

+1

-dain

On May 25, 2007, at 12:56 AM, Guillaume Nodet wrote:


I have tagged an XBean 3.0.1 version at
 http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.0.1/

Compared to 3.0, the only change is a fix in the main pom where
the version property has been left to 3.0-SNAPSHOT, thus causing
unwanted references to snapshots poms.

Please review the tag and vote for this release.  Once the vote  
passes,

I will upload the release to the repository.

[ ] +1 Release XBean 3.0.1 based on the proposed tag
[ ] +/- 0
[ ] -1 Do not release

Here's my +1

--
Cheers,
Guillaume Nodet

Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/

Re: replacing geronimo's servlet, jsp, and el specs

[Dain Sundstrom]

I don't think we can even if we wanted to.  Their annotation jar is a  
random collection of annotation classes from various specs:


javax/annotation/Generated.class
javax/annotation/PostConstruct.class
javax/annotation/PreDestroy.class
javax/annotation/Resource$AuthenticationType.class
javax/annotation/Resource.class
javax/annotation/Resources.class
javax/annotation/security/DeclareRoles.class
javax/annotation/security/DenyAll.class
javax/annotation/security/PermitAll.class
javax/annotation/security/RolesAllowed.class
javax/annotation/security/RunAs.class
javax/ejb/EJB.class
javax/ejb/EJBs.class
javax/persistence/PersistenceContext$PersistenceContextType.class
javax/persistence/PersistenceContext.class
javax/persistence/PersistenceContexts.class
javax/persistence/PersistenceUnit.class
javax/persistence/PersistenceUnits.class
javax/xml/ws/WebServiceRef.class
javax/xml/ws/WebServiceRefs.class

I find it very strange.

-dain

On May 23, 2007, at 1:38 PM, David Jencks wrote:

I haven't investigated the actual history but I think our  
annotation api jar was implemented independently of theirs so I am  
very reluctant to discard ours for theirs.


thanks
david jencks

On May 23, 2007, at 12:19 PM, Dain Sundstrom wrote:

IIRC the Tomcat has some non-compliant spec jars.  Specifically,  
the annotations-api.jar is not correct... it has javax/persistence/ 
PersistenceContext$PersistenceContextType.class, but that class is  
not an inner class and should be  
javax.persistence.PersistenceContextType


I'm guessing there are other problems with that jar and based on  
that I am concerned about the other spec jars they have.  Have we  
run the signature tests on these jars?


Paul, I don't follow the tomcat list, so can you mention the bad  
code to them?  Apache isn't allowed to ship non compliant  
implementations of specs.


Thanks,

-dain

On May 23, 2007, at 8:16 AM, Paul McMahan wrote:

Geronimo's servlet 2.5, jsp 2.1, and EL 1.0 specs were copied  
from tomcat6.   This was done because geronimo needed them for  
JEE5 but the tomcat team had not made those spec jars available  
in a maven repo.   See discussion at http://tinyurl.com/yvtj3f


Since that time there have been some concerns raised on  
[EMAIL PROTECTED] about ASF maintaining multiple copies of these specs,  
and at least one geronimo has expressed frustration about drift  
between the two versions.


Now thanks to Filip Hanik's efforts tomcat's JEE api jars are now  
available at the maven central repo.   If I verify that that  
these don't break TCK then are there any concerns with using them  
in geronimo 2.0 and deleting geronimo's copy of these specs from  
SVN?



Best wishes,
Paul

Re: replacing geronimo's servlet, jsp, and el specs

[Dain Sundstrom]

IIRC the Tomcat has some non-compliant spec jars.  Specifically, the  
annotations-api.jar is not correct... it has javax/persistence/ 
PersistenceContext$PersistenceContextType.class, but that class is  
not an inner class and should be  
javax.persistence.PersistenceContextType


I'm guessing there are other problems with that jar and based on that  
I am concerned about the other spec jars they have.  Have we run the  
signature tests on these jars?


Paul, I don't follow the tomcat list, so can you mention the bad code  
to them?  Apache isn't allowed to ship non compliant implementations  
of specs.


Thanks,

-dain

On May 23, 2007, at 8:16 AM, Paul McMahan wrote:

Geronimo's servlet 2.5, jsp 2.1, and EL 1.0 specs were copied from  
tomcat6.   This was done because geronimo needed them for JEE5 but  
the tomcat team had not made those spec jars available in a maven  
repo.   See discussion at http://tinyurl.com/yvtj3f


Since that time there have been some concerns raised on [EMAIL PROTECTED]  
about ASF maintaining multiple copies of these specs, and at least  
one geronimo has expressed frustration about drift between the two  
versions.


Now thanks to Filip Hanik's efforts tomcat's JEE api jars are now  
available at the maven central repo.   If I verify that that these  
don't break TCK then are there any concerns with using them in  
geronimo 2.0 and deleting geronimo's copy of these specs from SVN?



Best wishes,
Paul

Re: [BUILD] TRUNK: Failed for Revision: 535062

[Dain Sundstrom]

OpenEJB uses an automated system to publish snapshots, so if you need  
up to the minute code, you will have to build it yourself.


-dain

On May 3, 2007, at 9:19 PM, Jason Dillon wrote:

I'm in favor of using the snapshots.  If something has changed in  
openejb which would affect G, then new snaps should be deployed.


--jason


On May 3, 2007, at 8:56 PM, Jarek Gawor wrote:


Btw, trunk builds fine with the latest published OpenEJB snapshot but
fails with OpenEJB trunk code. I will try to fix it so it works with
both but maybe our automatic build should not build OpenEJB  
locally...

or maybe we should have 2 builds: one with published OpenEJB snapshot
and another one with OpenEJB trunk.

Jarek

On 4 May 2007 03:06:25 -, [EMAIL PROTECTED]  
<[EMAIL PROTECTED]> wrote:

OpenEJB trunk at 535060
Geronimo Revision: 535062 built with tests skipped

See the full build-2300.log file at http://people.apache.org/ 
~prasad/binaries/20070503/build-2300.log


Downloading: http://tomcat.apache.org/dev/dist/m2-repository/org/ 
apache/ws/commons/neethi/neethi/2.0/neethi-2.0.jar
[WARNING] Unable to get resource  
'org.apache.ws.commons.neethi:neethi:jar:2.0' from repository  
tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository)
Downloading: http://people.apache.org/repo/m2-incubating- 
repository//org/apache/ws/commons/neethi/neethi/2.0/neethi-2.0.jar
[WARNING] Unable to get resource  
'org.apache.ws.commons.neethi:neethi:jar:2.0' from repository  
apache-incubator (http://people.apache.org/repo/m2-incubating- 
repository/)
Downloading: http://repo1.maven.org/maven2/org/apache/ws/commons/ 
neethi/neethi/2.0/neethi-2.0.jar

28K downloaded
Downloading: http://tomcat.apache.org/dev/dist/m2-repository/org/ 
springframework/spring-web/2.0.4/spring-web-2.0.4.jar
[WARNING] Unable to get resource 'org.springframework:spring- 
web:jar:2.0.4' from repository tomcat-m2-repo (http:// 
tomcat.apache.org/dev/dist/m2-repository)
Downloading: http://people.apache.org/repo/m2-incubating- 
repository//org/springframework/spring-web/2.0.4/spring- 
web-2.0.4.jar
[WARNING] Unable to get resource 'org.springframework:spring- 
web:jar:2.0.4' from repository apache-incubator (http:// 
people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/org/springframework/ 
spring-web/2.0.4/spring-web-2.0.4.jar

148K downloaded
Downloading: http://tomcat.apache.org/dev/dist/m2-repository/ 
javax/xml/ws/jaxws-api/2.0/jaxws-api-2.0.jar
[WARNING] Unable to get resource 'javax.xml.ws:jaxws-api:jar:2.0'  
from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/ 
m2-repository)
Downloading: http://people.apache.org/repo/m2-incubating- 
repository//javax/xml/ws/jaxws-api/2.0/jaxws-api-2.0.jar
[WARNING] Unable to get resource 'javax.xml.ws:jaxws-api:jar:2.0'  
from repository apache-incubator (http://people.apache.org/repo/ 
m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/ 
2.0/jaxws-api-2.0.jar

23K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/apache/cxf/cxf-rt-bindings-soap/2.0-incubator-SNAPSHOT/cxf-rt- 
bindings-soap-2.0-incubator-20070502.014010-3.jar

81K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/apache/cxf/cxf-common-schemas/2.0-incubator-SNAPSHOT/cxf- 
common-schemas-2.0-incubator-20070502.014010-3.jar

41K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/apache/cxf/cxf-rt-frontend-jaxws/2.0-incubator-SNAPSHOT/cxf- 
rt-frontend-jaxws-2.0-incubator-20070502.014010-3.jar

200K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/apache/cxf/cxf-common-utilities/2.0-incubator-SNAPSHOT/cxf- 
common-utilities-2.0-incubator-20070502.014010-3.jar

169K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/apache/cxf/cxf-rt-transports-http/2.0-incubator-SNAPSHOT/cxf- 
rt-transports-http-2.0-incubator-20070502.014010-3.jar

118K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/apache/cxf/cxf-api/2.0-incubator-SNAPSHOT/cxf-api-2.0- 
incubator-20070502.014010-3.jar

210K downloaded
Downloading: http://tomcat.apache.org/dev/dist/m2-repository/org/ 
mortbay/jetty/jetty-util/6.1.2rc0/jetty-util-6.1.2rc0.jar
[WARNING] Unable to get resource 'org.mortbay.jetty:jetty- 
util:jar:6.1.2rc0' from repository tomcat-m2-repo (http:// 
tomcat.apache.org/dev/dist/m2-repository)
Downloading: http://people.apache.org/repo/m2-incubating- 
repository//org/mortbay/jetty/jetty-util/6.1.2rc0/jetty- 
util-6.1.2rc0.jar
[WARNING] Unable to get resource 'org.mortbay.jetty:jetty- 
util:jar:6.1.2rc0' from repository apache-incubator (http:// 
people.apache.org/repo/m2-incubating-repository/)
Downloading: http://repo1.maven.org/maven2/org/mortbay/jetty/ 
jetty-util/6.1.2rc0/jetty-util-6.1.2rc0.jar

120K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/a

Re: [jira] Commented: (GERONIMO-3137) Servlets must rollback uncommitted transaction when the service method exits

[Dain Sundstrom]

On May 4, 2007, at 3:00 AM, Daniel Alheiros wrote:

Do you think it could be interesting logging this in a WARN level  
to make
the application developer to fix it? I believe it will only happen  
caused by

bad code, so...


The rule appears to be:

if servlet started a UT and it is marked rollback only,
rollback the ut on servlet exit
else if the servlet is the original web request (not a dispatch) and  
there is an open tx

rollback the ut on servlet exit
otherwise
leave the transaction open

The rule is a bit strange, but that is the way they seem to want it.   
Anyway, the first condition can be caused by an application exception  
where the code does ut.setRollbackOnly.  The second condition is a  
programming error and as you suggest, should be logged at WARN.


-dain

[jira] Created: (GERONIMO-3137) Servlets must rollback uncommitted transaction when the service method exits

[Dain Sundstrom (JIRA)]

Servlets must rollback uncommitted transaction when the service method exits


 Key: GERONIMO-3137
 URL: https://issues.apache.org/jira/browse/GERONIMO-3137
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: web
Reporter: Dain Sundstrom
 Assigned To: David Jencks


Servlets must rollback uncommitted transaction when the service method exits.  
The servlet should check for a tx on entry and if one is not present on entry 
but there is one on exit, it should be rolled back.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3125) AdminObjectRefBuilder does not handle UserTransaction resource-env-refs

[Dain Sundstrom (JIRA)]

AdminObjectRefBuilder does not handle UserTransaction resource-env-refs
---

 Key: GERONIMO-3125
 URL: https://issues.apache.org/jira/browse/GERONIMO-3125
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Reporter: Dain Sundstrom
 Assigned To: David Jencks


In Jee 5 is is legal to have @Resource and , to add a 
UserTransaction (or EJB Context) to the ENC.  This AdminObjectRefBuilder does 
not understand this yet and attempts to resolve an AdminObject for these refs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] 2.0-M5 rc1 binaries available for review and vote.

[Dain Sundstrom]

+1  Ship it!

-dain

On Apr 25, 2007, at 11:38 PM, Matt Hogstrom wrote:

The 2.0-M5 binaries are available at http://people.apache.org/ 
~hogstrom/2.0-M5-rc1


The binaries addressed a problem seen in 2.0-M4 which was  
subsequently scrubbed where 2.0-Mn and 2.0-Mn-SNAPSHOT binaries  
were included.  Building with a clean repo has resolved that issue.


It is possible to build this release but as it is dependent on  
SNAPSHOTs it is not expected that it will have a long lived  
repeatable build (as has been the case in previous Milestones).   
Given that SNAPSHOTs are really for users to pick up a work in  
progress this should not be an issues as a new Milestone will  
generally be available in the next 30 days.


Thanks for taking time to review these binaries.

Please use this thread for your vote and the DISCUSS thread for  
comments.  Thanks


[ ] +1 Approve the binaries for release
[ ] 0
[ ] -1 Do not ship binaries.

This vote will conclude on April 29th at 0300 ET unless superceded  
by a new -rc vote.

Re: [DISCUSS] 2.0-M5 (rc1) binaries available

[Dain Sundstrom]

I think doing a monthly or simi-monthy unstable would be excellent,  
and would save a lot of work.  As for naming, I don't really care.   
We are releasing milestones right now, and they don't really  
represent "defined" goals anyway.


-dain


On Apr 26, 2007, at 10:56 AM, Donald Woods wrote:

I like the idea of publishing monthly builds, but calling them a  
Milestone when there was no defined and met milestone doesn't quite  
make sense...


Why not just ask Prasad (or Jason w/ GBuild) to include the  
testsuite in the daily run that includes the unit tests -


   Subject: [BUILD] TRUNK: Successful for Revision: 532672
   Date: 26 Apr 2007 09:37:43 -
   From: [EMAIL PROTECTED]
   Reply-To: dev@geronimo.apache.org
   To: [EMAIL PROTECTED]

   OpenEJB trunk at 532669
   Geronimo Revision: 532672 built with tests included
   . . .

and then just pick one of those that passes every week to publish  
to the snapshot repo and to publish for users to download?  That  
way, as the testsuite gains more component coverage, we'll  
naturally move towards a more formal test process before releases  
are selected to vote on.



-Donald

Matt Hogstrom wrote:
Here is a question to ponder.  Would anyone object if I simply  
made these binaries available from people as a monthly unstable  
release?  Given the amount of time it takes to spin this up and  
vote I'd rather just pick an svn version and make it available.  I  
think it burns up a lot of people's time to follow the release  
process.  Simply pop out the binary, let people play with it and  
if things are broken there is always trunk.  Perhaps we could move  
to a weekly unstable.

Anyway, I'd like some thoughts on this.
On Apr 26, 2007, at 2:39 AM, Matt Hogstrom wrote:

Starting DISCUSS thread if necessary for this release.

Re: Geronimo/Tuscany integration

[Dain Sundstrom]

I suggest you get option 1 working before attempting option 2.  I  
suspect you will find lots of bugs and mismatched assumptions.  Once  
that is working, option 2 will be much easier to implement since you  
know it "Should Work".


-dain

On Apr 25, 2007, at 1:23 PM, Jay D. McHugh wrote:


Hello Raymond,

I think it would almost be a shame if the only option for including  
Tuscany in Geronimo was to package the runtime jar in individual  
WAR files.


Tuscany would make an excellent (I think) plugin.

Option 2 definitely.

Jay

Raymond Feng wrote:

Hi, Geronimo community.

As you may know, Tuscany is an Apache project under incubation to  
provide an open source SOA infrastructure. For more information,  
you can visit http://cwiki.apache.org/TUSCANY/.


Tuscany implements the SCA specification (http://www.osoa.org) and  
allows you to develop and run SCA components in various hosting  
environments. We currently integrate with Tomcat and Jetty and  
would like to try to integrate with Geronimo as well. I would like  
to start some discussions here to figure out the best way to do that.


After some preliminary investigations of Geronimo, I feel that  
there are two options on the table so far.


1) Shallow integration: Package SCA applications together with the  
Tuscany runtime as WARs and deploy them Geronimo as Web  
applications. It's basically the integration with a Web container.  
We register a TuscanyContextListner (which implements  
javax.servlet.ServletContextListener) in web.xml to start/stop the  
Tuscany runtime when the web application is started/stopped.


This will allow us to support the following use cases:
* A Web application hosted by Geronimo with business logic written  
as SCA components
* Expose one or more SCA components as Web services over HTTP as  
supported by the Web container.


2) Deep integration: We package the Tuscany runtime and its  
dependencies as Geronimo modules and deploy them to Geronimo  
(which is similar to how Tomcat is integrated as the Web container  
for Geronimo). We can then create a Tuscany plugin (a collection  
of modules) so that it can be added to Geronimo. The Tuscany  
container will then handle SCA-specific deployment plans to  
install SCA applications and provide runtime infrastructure for them.


On top of Option 2, we could further integrate Geronimo's J2EE  
capabilities such as EJB, WS, JMS and JCA with Tuscany. Basically,  
SCA components will be able to access JEE services (using SCA  
composite references) and SCA components will be able to expose  
services (SCA composite services) over JEE protocols as well.


This will allow us to support the following use cases:
* Any J2EE application hosted by Geronimo would be able to take  
advantage of SCA programming model
* Provide SCA services over various protocols such as RMI/IIOP,  
JMS and JCA
* Invoke existing JEE applications (EJB, JMS backend, JCA-based  
EIS or Web Services) from SCA components


Any thoughts?

Thanks,
Raymond
Apache Tuscany committer

Is the connector problem fixed?

[Dain Sundstrom]

Matt,

I see you are wrapping the G-M5 release.  Does that mean you fixed  
the connector problem and I should look at respinning the 1.2 release.


-dain

Re: Help needed with geronimo.sh

[Dain Sundstrom]

+1

I think the platform scripts should be as thin as possible

-dain

On Apr 24, 2007, at 12:38 PM, Jason Dillon wrote:


Well, that sounds better than putting that muck into platform scripts.

Though, why not simplify this even more and force users to make the  
correct directories with the right configuration, and then just die  
quickly if the directory is missing with an informative error  
message to that effect.


--jason


On Apr 24, 2007, at 12:32 PM, Anita Kulshreshtha wrote:


  The other option is to update MainConfigurationBootstrapper as
follows:
1. if geronimo.org.apache.geronimo.server.name system property is not
set, set it to 'geronimo'.
2. If 'geronimo' dir does not exist, create one and copy 'var' to it.
3. do the rest...

Thanks
Anita

--- Jason Dillon <[EMAIL PROTECTED]> wrote:


Why is it making geronimo/var?  Its usually much better to let Java
handle making directories and other complicated tasks and keep
platform scripts as simple as possible.

--jason


On Apr 24, 2007, at 4:51 AM, Anita Kulshreshtha wrote:


   Could someone please help me with testing a unix version of
modified
geronimo.bat? The patch for geronimo.bat is attached to
http://issues.apache.org/jira/browse/GERONIMO-3011#action_12491001
   The new geronimo.sh should create a geronimo/var and run

geronimo

from it when bin\startup is used.

Thanks
Anita

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com






__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: [VOTE] Release XBean 3.0

[Dain Sundstrom]

+1

-dain

On Apr 17, 2007, at 12:33 PM, Guillaume Nodet wrote:


I have uploaded an XBean 3.0 release at
 http://people.apache.org/~gnodet/xbean-3.0/repo/org/apache/xbean/

This repo also contains older releases so that the meta-data is  
correct.


[ ] +1 Release XBean 3.0
[ ] 0 No opinion
[ ] -1 Do not release

--
Cheers,
Guillaume Nodet

Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release geronimo-jpa_3.0_spec-1.1 jar (1st vote)

[Dain Sundstrom]

+1

-dain

On Apr 18, 2007, at 9:22 AM, Matt Hogstrom wrote:

Please review and vote on the binaries for geronimo- 
jpa_3.0_spec-1.1.  the binaries can be seen in:


http://people.apache.org/~hogstrom/spec-rc1

[ ] +1 Release these binaries
[ ] 0
[ ] -1  Do not release these binaries

This vote will conclude Saturday April 21 at 1300 Eastern

Re: [VOTE] Release geronimo-annotation_1.0_spec-1.1 jar (1st vote)

[Dain Sundstrom]

+1

-dain

On Apr 18, 2007, at 9:23 AM, Matt Hogstrom wrote:

Please review and vote on the binaries for geronimo- 
annotation_1.0_spec-1.1.  the binaries can be seen in:


http://people.apache.org/~hogstrom/spec-rc1

[ ] +1 Release these binaries
[ ] 0
[ ] -1  Do not release these binaries

This vote will conclude Saturday April 21 at 1300 Eastern

Re: [VOTE] Release geronimo-jta_1.1_spec-1.1 jar (1st vote)

[Dain Sundstrom]

+1

-dain

On Apr 18, 2007, at 9:23 AM, Matt Hogstrom wrote:

Please review and vote on the binaries for geronimo- 
jta_1.1_spec-1.1.  the binaries can be seen in:


http://people.apache.org/~hogstrom/spec-rc1

[ ] +1 Release these binaries
[ ] 0
[ ] -1  Do not release these binaries

This vote will conclude Saturday April 21 at 1300 Eastern

Re: [VOTE] Release geronimo-ws-metadata_2.0_spec-1.1 jar (1st vote)

[Dain Sundstrom]

+1

-dain

On Apr 18, 2007, at 9:22 AM, Matt Hogstrom wrote:

Please review and vote on the binaries for geronimo-ws- 
metadata_2.0_spec-1.2.  the binaries can be seen in:


http://people.apache.org/~hogstrom/spec-rc1

[ ] +1 Release these binaries
[ ] 0
[ ] -1  Do not release these binaries

This vote will conclude Saturday April 21 at 1300 Eastern

Re: [discuss] Release Geronimo 1.2

[Dain Sundstrom]

Can you create JIRAs for these?

On Apr 9, 2007, at 11:03 AM, Kevan Miller wrote:



Aside from the ongoing technical discussion, I have the following  
comments on the proposed 1.2 binaries and source:


 1) I don't see release notes in the assemblies. Which means no  
instructions on what to with a binary once it has been installed. I  
thought Hernan had generated some release-notes. Not sure what  
happened to them...

 2) Following files have incorrect source file headers:
 modules/geronimo-connector/src/test/java/org/apache/geronimo/ 
connector/mock/ConnectionExtension.java
 modules/geronimo-connector/src/test/java/org/apache/geronimo/ 
connector/outbound/connectiontracking/ 
ConnectionTrackingCoordinatorProxyTest.java


These wouldn't be a critical problem since we don't distribute test  
code, but we should fix them now that we have a chance.


-dain

Re: [vote] Release Geronimo 1.2

[Dain Sundstrom]

I agree and am switching to a -1 also.

At the same time, we can fix the other minor issues people pointed  
out and respin.


-dain

On Apr 9, 2007, at 10:51 AM, Matt Hogstrom wrote:

I'll switch to a -1 given the instabiity of the connection  
manager.  I'll help to work on this as its the same code for 2.0.


On Apr 4, 2007, at 8:01 PM, Dain Sundstrom wrote:

The 1.2 release cut and awaiting your vote!  All the files are  
available in a staging area in my home dir on people.


http://people.apache.org/~dain/dist
   geronimo-1.2-src
   geronimo-framework-1.2
   geronimo-jetty-minimal-1.2
   geronimo-tomcat-minimal-1.2
   geronimo-jetty-j2ee-1.2
   geronimo-tomcat-j2ee-1.2

Additionally the maven repository with all of the modules,  
configs, assemblies, etc. is here:


  http://people.apache.org/~dain/stage/org/apache/geronimo

All archives contain LICENSE and NOTICE.  Each binary jar is also  
accompanied by source, javadoc, pom and all are signed, md5-ed,  
and secure-hashed.  Keys file available here:


  http://people.apache.org/dist/geronimo/KEYS

Svn tag is here:

  http://svn.apache.org/repos/asf/geronimo/server/tags/1.2

Here's my +1!

-dain

Re: Outstanding SNAPSHOTs in Geronimo (informational)

[Dain Sundstrom]

I'm about to move OpenJPA to 0.9.7-SNAPSHOT which contains some  
critical fixes for Derby and some query styles.  The OpenJPA project  
is currently working on wrapping this release, so hopefully this  
SNAPSHOT will only be around for a few weeks.


-dain

On Apr 5, 2007, at 8:43 AM, Matt Hogstrom wrote:

Here are a list of artifacts that we are using that are currently  
in SNAPSHOT status.  I wanted to get my head around what we need to  
do for the 2.0 release when we're ready and thought that people  
might find this interesting.  Lot's of work to do.


If there are any of the items below that you know can be released  
let me know and that will help reduce the number of moving parts  
for 2.0.


Under Apache Geronimo

*Genesis*
org.apache.geronimo.genesis.config  / project-config / 1.2-SNAPSHOT


*Specs*
org.apache.geronimo.specs / geronimo-activation_1.1_spec / 1.0- 
SNAPSHOT

org.apache.geronimo.specs / geronimo-el_1.0_spec / 1.0-SNAPSHOT
org.apache.geronimo.specs / geronimo-javaee- 
deployment_1.1MR3_spec / 1.0-SNAPSHOT

org.apache.geronimo.specs / geronimo-jacc_1.1_spec / 1.0-SNAPSHOT
org.apache.geronimo.specs / geronimo-j2ee-management_1.1_spec / 1.0- 
SNAPSHOT

org.apache.geronimo.specs / geronimo-jsp_2.1_spec / 1.0-SNAPSHOT
org.apache.geronimo.specs / geronimo-stax-api_1.0_spec / 1.0-SNAPSHOT
org.apache.geronimo.specs / geronimo-servlet_2.5_spec / 1.1-SNAPSHOT
org.apache.geronimo.specs / geronimo-ws-metadata_2.0_spec / 1.1- 
SNAPSHOT



*Schema*
org.apache.geronimo.schema / geronimo-schema-jee_5 / 1.1-SNAPSHOT
org.apache.geronimo.schema / geronimo-schema-j2ee_1.4 / 1.1-SNAPSHOT


*JavaMail*
org.apache.geronimo.javamail / geronimo-javamail_1.4_mail / 1.1- 
SNAPSHOT



*Xbean*
org.apache.xbean / xbean-finder / 3.0-SNAPSHOT
org.apache.xbean / xbean-naming / 3.0-SNAPSHOT
org.apache.xbean / xbean-reflect / 3.0-SNAPSHOT


Outside of and independent of Apache Geronimo

*Yoko*
org.apache.yoko / yoko-core / 1.0-incubating-SNAPSHOT
org.apache.yoko / yoko-spec-corba / 1.0-incubating-SNAPSHOT
org.apache.yoko / yoko-rmi-spec / 1.0-incubating-SNAPSHOT
org.apache.yoko / yoko-rmi-impl / 1.0-incubating-SNAPSHOT


*ActiveMQ*
org.apache.activemq / activemq-core / 4.1-SNAPSHOT
org.apache.activemq / activemq-ra / 4.1-SNAPSHOT


*OpenEJB*
org.apache.openejb / openejb-core / 3.0-incubating-SNAPSHOT
org.apache.openejb / openejb-client / 3.0-incubating-SNAPSHOT
org.apache.openejb / openejb-ejbd / 3.0-incubating-SNAPSHOT
org.apache.openejb / openejb-axis / 3.0-incubating-SNAPSHOT


*Tomcat*
org.apache.tomcat / jasper-el / 6.0.10
org.apache.tomcat / jasper-jdt / 6.0.10
org.apache.tomcat.extras / juli / 6.0.10
org.apache.tomcat.extras / juli-adapters / 6.0.10
org.apache.tomcat / catalina-ha / 6.0.10
org.apache.tomcat / tribes / 6.0.10
org.apache.tomcat / coyote / 6.0.10
org.apache.tomcat / juli / 6.0.10


*MyFaces*
org.apache.myfaces.core / myfaces-api / 1.2.0-SNAPSHOT
org.apache.myfaces.core / myfaces-impl / 1.2.0-SNAPSHOT


*Jetty*
org.mortbay.jetty / jetty / 6.1-SNAPSHOT
org.mortbay.jetty / jetty-util / 6.1-SNAPSHOT


*WADI*
org.codehaus.wadi / wadi-core / 2.0M3-SNAPSHOT
org.codehaus.wadi / wadi-group / 2.0M3-SNAPSHOT
org.codehaus.wadi / wadi-tribes / 2.0M3-SNAPSHOT


*Axis*
org.apache.axis2 / axis2-saaj-api / SNAPSHOT
org.apache.axis2 / axis2-java2wsdl / SNAPSHOT
org.apache.axis2 / axis2-kernel / SNAPSHOT
org.apache.axis2 / axis2-adb / SNAPSHOT
org.apache.axis2 / axis2-jaxws-api / SNAPSHOT
org.apache.axis2 / axis2-jaxws / SNAPSHOT
org.apache.axis2 / axis2-metadata / SNAPSHOT
org.apache.axis2 / axis2-saaj / SNAPSHOT
org.apache.ws.commons.axiom / axiom-api / SNAPSHOT
org.apache.ws.commons.axiom / axiom-impl / SNAPSHOT
org.apache.ws.commons.axiom / axiom-dom / SNAPSHOT

org.apache.woden / woden / 1.0-incubating-SNAPSHOT

org.apache.ws.scout / scout / SNAPSHOT


*CXF*
org.apache.cxf / cxf-api / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-metacode / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-common-utilities / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-rt-core / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-rt-bindings-xml / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-rt-bindings-soap / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-rt-databinding-jaxb / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-rt-frontend-jaxws / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-rt-frontend-simple / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-rt-transports-http / 2.0-incubator-RC-SNAPSHOT
org.apache.cxf / cxf-tools-common / 2.0-incubator-RC-SNAPSHOT

*Plugins*
org.apache.maven.plugins / maven-enforcer-plugin / 1.0-alpha-1- 
SNAPSHOT

org.codehaus.mojo / xmlbeans-maven-plugin / 2.0.1-SNAPSHOT
org.codehaus.mojo / jspc-maven-plugin / 1.4.7-SNAPSHOT

Re: [vote] Release Geronimo 1.2

[Dain Sundstrom]

So are you saying that you do not want to no release this software  
until these are fixed?


This is a vote thread to determine if we should release this software  
with it's current warts or run another fix release cycle.


-dain

On Apr 5, 2007, at 6:44 AM, Hernan Cunico wrote:


Thanks for putting this together.
I did some basic testing (did not test security) on the binaries  
and this is what I found so far.


- *geronimo-jetty-j2ee-1.2* takes around 30 sec to start, IFRC it  
used to be under 20 and it also takes longer to shutdown. Tomcat is  
about 10 sec faster for both start and stop.


- Both J2EE distros still have the problem of not having accessible  
a newly created embedded Derby DB and still require a Geronimo  
restart.


	09:28:46,296 ERROR [MCFConnectionInterceptor] Error occurred  
creating ManagedConnection for  
[EMAIL PROTECTED]
	javax.resource.spi.ResourceAllocationException: Unable to obtain  
physical connection to jdbc:derby:SomeDB


- All 4 distros throw this exception on shutdown.

Server shutdown begun
	09:09:41,296 WARN  [BasicLifecycleMonitor] Exception occured while  
notifying listener

java.lang.NullPointerException
		at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding 
(GBeanBinding.java:159)
		at org.apache.geronimo.gjndi.binding.GBeanBinding 
$GBeanLifecycleListener.stopped(GBeanBinding.java:108)
		at  
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEven 
t(BasicLifecycleMonitor.java:197)
		at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access 
$500(BasicLifecycleMonitor.java:41)
		at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor 
$RawLifecycleBroadcaster.fireStoppedEvent 
(BasicLifecycleMonitor.java:259)
		at  
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop 
(GBeanInstanceState.java:359)
		at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop 
(GBeanInstanceState.java:188)
		at org.apache.geronimo.gbean.runtime.GBeanInstance.stop 
(GBeanInstance.java:551)
		at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean 
(BasicKernel.java:423)
		at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop 
(GBeanInstanceState.java:180)
		at org.apache.geronimo.gbean.runtime.GBeanInstance.stop 
(GBeanInstance.java:551)
		at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean 
(BasicKernel.java:423)
		at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop 
(GBeanInstanceState.java:180)
		at org.apache.geronimo.gbean.runtime.GBeanInstance.stop 
(GBeanInstance.java:551)
		at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean 
(BasicKernel.java:423)
		at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop 
(GBeanInstanceState.java:180)
		at org.apache.geronimo.gbean.runtime.GBeanInstance.stop 
(GBeanInstance.java:551)
		at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean 
(BasicKernel.java:423)
		at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop 
(GBeanInstanceState.java:180)
		at org.apache.geronimo.gbean.runtime.GBeanInstance.stop 
(GBeanInstance.java:551)
		at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean 
(BasicKernel.java:423)
		at org.apache.geronimo.kernel.config.KernelConfigurationManager 
$ShutdownHook.run(KernelConfigurationManager.java:311)
		at  
org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks 
(BasicKernel.java:668)
		at org.apache.geronimo.kernel.basic.BasicKernel.shutdown 
(BasicKernel.java:645)

at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:225)
Server shutdown completed

Cheers!
Hernan

Dain Sundstrom wrote:
The 1.2 release cut and awaiting your vote!  All the files are  
available in a staging area in my home dir on people.

http://people.apache.org/~dain/dist
   geronimo-1.2-src
   geronimo-framework-1.2
   geronimo-jetty-minimal-1.2
   geronimo-tomcat-minimal-1.2
   geronimo-jetty-j2ee-1.2
   geronimo-tomcat-j2ee-1.2
Additionally the maven repository with all of the modules,  
configs, assemblies, etc. is here:

  http://people.apache.org/~dain/stage/org/apache/geronimo
All archives contain LICENSE and NOTICE.  Each binary jar is also  
accompanied by source, javadoc, pom and all are signed, md5-ed,  
and secure-hashed.  Keys file available here:

  http://people.apache.org/dist/geronimo/KEYS
Svn tag is here:
  http://svn.apache.org/repos/asf/geronimo/server/tags/1.2
Here's my +1!
-dain

Re: [vote] Release openejb-2.3-incubating

[Dain Sundstrom]

Jason and I chatted on irc and decided there isn't much we can do  
about these, or the fact that the repos aren't as reliable as we'd  
like.  To address this, I have saved off the repository used to  
create the release here:


  http://people.apache.org/~dain/dist/geronimo-1.2-build- 
repository.tar.bz


This way we will *always* have everything maven needs to rebuild the  
server from source.


-dain

On Apr 4, 2007, at 5:10 PM, Jason Dillon wrote:



Copying g list because the same problem is relevant to the g 1.2  
release.



This is still using some artifacts which are only in snapshot  
repositories:


 * xmlbeans-maven-plugin 2.0.1-20060627.031204-7
 * maven-deploy-plugin 2.3-20061210.174233-3
 * maven-gpg-plugin 1.0-alpha-2-20061214.035657-1

While the version does not have SNAPSHOT in it... don't let that  
trick you into thinking these are not SNAPSHOTS, because they are.   
While the release plugin will let you roll something out like this,  
use of these pinned snapshots will limit the build-ability of this  
tree in the future.


While there is no real guarantee that any artifact in any repo  
(snap or not) will really be around in the future (short or long  
term), there is a high possibility that artifacts in a snap repo  
will not be around for very long.  And even when using a pinned  
snapshot the fact still remains that the storage of that artifact  
is transient and will almost certainly not be available at some  
time in the future, which will cause this tree (and the G 1.2 tree)  
to be unbuildable w/o source changes.


The main problem here is the xmlbeans-maven-plugin  
2.0.1-20060627.031204-7, which affects the G 1.2 build as well.   
The others are for release support and are in a profile which is  
not enabled by default.


 * * *

I mention this not to derail the release... because I really want  
this to get out so we can get G 1.2 out.  But we would really be in  
a much better position to support the ongoing build-ability of this  
tree if we did not have *any* artifacts which are required to build  
that are only available in a transient snapshot repository.


If its a pain to get a release release from the mojo folks working  
on the xmlbeans-maven-plugin, then we need to add these artifacts  
(and any snaps which it may be depending on, I didn't look), into a  
local repository that is checked into svn, just like G does (ie.  
http://svn.apache.org/repos/asf/geronimo/server/branches/1.2/ 
repository/ ).


--jason


On Apr 4, 2007, at 4:52 PM, Dain Sundstrom wrote:


All,

The release is cut and awaiting your vote!  All the files are  
available in a staging area in my home dir on people.


http://people.apache.org/~dain/stage/org/apache/openejb/

   itests-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
   modules-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
   openejb-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
   openejb-axis-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
   openejb-builder-2.3-incubating (jar,source,javadoc,pom) 
{asc,md4,sha1}
   openejb-corba-2.3-incubating (jar,source,javadoc,pom) 
{asc,md4,sha1}
   openejb-corba-builder-2.3-incubating (jar,source,javadoc,pom) 
{asc,md4,sha1}

   openejb-core-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
   openejb-itests-core-2.3-incubating (jar,source,javadoc,pom) 
{asc,md4,sha1}
   openejb-pkgen-builder-2.3-incubating (jar,source,javadoc,pom) 
{asc,md4,sha1}

   openejb-yoko-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}

All jars contain DISCLAIMER, LICENSE, and NOTICE.  Each binary jar  
is also accompanied by source, javadoc, pom and all are signed,  
md5-ed, and secure-hashed.  Keys file available here:


   http://people.apache.org/repo/m2-incubating-repository/org/ 
apache/openejb/KEYS


Svn tag is here:

   http://svn.apache.org/repos/asf/incubator/openejb/tags/ 
openejb-2.3/


Here's my +1!

-dain

Re: svn commit: r525641 - in /geronimo/server/tags: 1.2.0/ 1.2/

[Dain Sundstrom]

On Apr 4, 2007, at 4:52 PM, Jason Dillon wrote:

Hey, just curious... did you use the release plugin to make this  
stuff, or did you have to roll it by hand?


I had to do it by hand.  Last time I talked to Jason Van Zyl about  
this, he said it won't work with Geronimo due to our use of  
properties for version numbers.


One problem with hand rolling is that it won't get the  bits  
updated as would happen using the release plugin.


I think its fine for now, but I hope we can figure out how to use  
the std tools for 2.0 and newer releases.  Should be possible, but  
I think we will have to dance around a few problems with Maven to  
make it happen.


Me 2.  It is a real PITA to release this stuff by hand.

-dain

[vote] Release Geronimo 1.2

[Dain Sundstrom]

The 1.2 release cut and awaiting your vote!  All the files are  
available in a staging area in my home dir on people.


http://people.apache.org/~dain/dist
   geronimo-1.2-src
   geronimo-framework-1.2
   geronimo-jetty-minimal-1.2
   geronimo-tomcat-minimal-1.2
   geronimo-jetty-j2ee-1.2
   geronimo-tomcat-j2ee-1.2

Additionally the maven repository with all of the modules, configs,  
assemblies, etc. is here:


  http://people.apache.org/~dain/stage/org/apache/geronimo

All archives contain LICENSE and NOTICE.  Each binary jar is also  
accompanied by source, javadoc, pom and all are signed, md5-ed, and  
secure-hashed.  Keys file available here:


  http://people.apache.org/dist/geronimo/KEYS

Svn tag is here:

  http://svn.apache.org/repos/asf/geronimo/server/tags/1.2

Here's my +1!

-dain

Re: Creating OpenEJB 2.3 and Geronimo 1.2 binaries

[Dain Sundstrom]

On Apr 3, 2007, at 7:39 PM, Dain Sundstrom wrote:

I'm going to attempt to create binaries for OpenEJB 2.3 and  
Geronimo 1.2 tonight.  Since OpenEJB 2.3 and Geronimo 1.2 are  
highly coupled we need to release them together.  With luck, we'll  
have some files to test and start voting on tomorrow.


Got the tags cut and everything seems to be building and publishing  
ok, but instead of trying to stay up late and finish this, I'm going  
to wait and start on it again tomorrow morning.


-dain

Re: svn commit: r524934 - /geronimo/server/trunk/STATUS

[Dain Sundstrom]

On Apr 2, 2007, at 7:30 PM, Jason Dillon wrote:


On Apr 2, 2007, at 2:42 PM, [EMAIL PROTECTED] wrote:
+Status:  The release is stalled waiting for final releases  
from dependent

+  projects.  Specifically, we need releases from:
+Showstoppers:
+  Yoko 1.0 - Contains many fixes to CORBA interoperability


We have a Yojo release for G 1.2

+  ActiveMQ 4.1.1 - We need a release which contains AMQ-1165  
and AMQ-1088


And today *finally* 4.1.1 was released.


+  OpenEJB 2.3 - Once Yoko is released, OpenEJB 2.3 can be  
release


OpenEJB and G must be released at the same time due to coupling  
issues.


I started up the TCK for G 1.2 with the AMQ 4.1.1 binaries, if that  
passes then we need to coordinate with OpenEJB to make a release at  
the same time G 1.2 is released.  Hope to know more about that  
soon. :-)


I'm planning on kicking off the process tomorrow.

-dain

[jira] Closed: (GERONIMO-2972) Bind JavaMail Session to Global JNDI

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom closed GERONIMO-2972.


   Resolution: Fixed
Fix Version/s: 2.0-M4
 Assignee: Christopher M. Cardona  (was: Dain Sundstrom)

Committed revision 524985. 

Thanks!

> Bind JavaMail Session to Global JNDI
> 
>
> Key: GERONIMO-2972
> URL: https://issues.apache.org/jira/browse/GERONIMO-2972
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: mail
>Affects Versions: 2.0-M5
>Reporter: Christopher M. Cardona
> Assigned To: Christopher M. Cardona
> Fix For: 2.0-M4
>
> Attachments: GERONIMO-2972.patch, mailsession1-plan.xml, 
> sendmail.war, testjndi.war
>
>
> Auto bind JavaMail Session objects to Global JNDI.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-2972) Bind JavaMail Session to Global JNDI

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom reassigned GERONIMO-2972:


Assignee: Dain Sundstrom  (was: Christopher M. Cardona)

> Bind JavaMail Session to Global JNDI
> 
>
> Key: GERONIMO-2972
> URL: https://issues.apache.org/jira/browse/GERONIMO-2972
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: mail
>Affects Versions: 2.0-M5
>Reporter: Christopher M. Cardona
> Assigned To: Dain Sundstrom
> Attachments: GERONIMO-2972.patch, mailsession1-plan.xml, 
> sendmail.war, testjndi.war
>
>
> Auto bind JavaMail Session objects to Global JNDI.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] 2.0-M4 Binaries available (rc1)

[Dain Sundstrom]

+1

-dain

On Apr 1, 2007, at 2:54 AM, Matt Hogstrom wrote:

I have placed the 2.0-M4 binaries out on http://people.apache.org/ 
~hogstrom/2.0-M4-rc1 for you to take a look at.  (They are  
uploading as I write this).


I have done some testing with DayTrader.  There is an issue in  
connecting with he MDB container which still needs to be worked out  
so the application will not deploy as is.  However, given the  
scopwe of function DayTrader covers as well as all the late code  
drops I don't see an issue with that.  Smaller samples should be ok  
and tests look good.  Given that we're in the final stages of  
testing I'd like to get this Milestone on the wire as is and fix  
issues in trunk.  Users that pull this binary and report issues  
will help us in the Drive to 5.


Other than that limitation I think this Milestone looks ready to go.

After reviewing the content please cast your vote.

[ ] +1 - Release these binaries
[ ]   0
[ ] -1 Do not release these binaries (provide reason)

This vote will conclude on April 4th at 0600 Eastern.

Thanks!

Re: G 1.2 && xmlbeans-maven-plugin 2.0.1-20060627.031204-7

[Dain Sundstrom]

If it works with the latest release we can switch to that; otherwise  
IMO a pinned snapshot is fine.  It is just a maven plugin after all.


-dain

On Mar 30, 2007, at 3:46 PM, Jason Dillon wrote:

Anyone know whats up with the xmlbeans-maven-plugin wrt server/ 
branches/1.2?  Its currently using a pinned snapshot.  While this  
is fine for M/RC releases, its not for officials, since its still a  
snapshot and the artifact could be removed tomorrow for all we know.


We need to get this dependency sorted before we can release 1.2.   
It appears this is the only dependency using a pinned snapshot like  
this for 1.2, which is good there aren't more of them.


Anyone know?

--jason

[jira] Assigned: (GERONIMO-3046) When starting Daytrader after deploy on 2.0-SNAPSHOT ejb-jar is started before its dependencies have been started

[Dain Sundstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dain Sundstrom reassigned GERONIMO-3046:


Assignee: Matt Hogstrom  (was: Dain Sundstrom)

I believe this is fixed with r524261

> When starting Daytrader after deploy on 2.0-SNAPSHOT ejb-jar is started 
> before its dependencies have been started
> -
>
> Key: GERONIMO-3046
> URL: https://issues.apache.org/jira/browse/GERONIMO-3046
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M4, 2.0-M5
>Reporter: Matt Hogstrom
> Assigned To: Matt Hogstrom
> Fix For: 2.0-M4
>
>
> Testing deployment of Daytrader on Geronimo 2.0 - M4 (as well as trunk) the 
> dt-ejb.jar is started before the messaging component it depends on.  As a 
> consequence, startup of the application fails as a dependent resource (a 
> messaging queue) is not found.
> Talked to Dain about this and he thinks he knows where this needs to be 
> addressed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Tomcat m2 repo?

[Dain Sundstrom]

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/dev/dist/m2- 
repository, but


Ug... why on earth is Tomcat not just using the standard Maven 2  
repos that the rest of us have to use?  This is so annoying.   If  
they just published to m2-ibiblio-rsync-repository then they  
would be done already.

wow, you're such a joy to be around ;)


Sorry, this repo stuff is a sore subject for me.  I've been trying  
to keep things orderly (and limited) and new repos just keep poping  
up and into our build.  This has been going on for a while now,  
though it has gotten better.


Anyways, nothing personal... I am just a little annoyed with all  
the repo related issues in whole.


If you remember back, Ant was originally developed to build Tomcat,  
so the odds of them dropping Ant are pretty slim.  Now they maybe  
willing to add the maven ant tasks to publish to the maven repo, but  
I suggest you ask really nicely.


-dain

Re: org.apache.j2g

[Dain Sundstrom]

I'm guessing one day there may be more then just a JBoss converter,  
so you may want to go with something like  
org.apache.geronimo.convert.jboss.  I'm not sure "convert" is best  
word... maybe migrate.


-dain

On Mar 26, 2007, at 1:02 PM, Jason Dillon wrote:


I asked about this before, but got no answer.

Why is the code for "geronimo/sandbox/j2g" using "org.apache.j2g"  
as a package name?  This seems *very* inconsistent wrt other  
codelines which are hosted by the geronimo svn.


Why?

--jason

Re: Where is the src for org.apache.geronimo.gjndi.GlobalContextGBean

[Dain Sundstrom]

You should ask on the xbean mailing list.

-dain

On Mar 20, 2007, at 4:34 PM, Jason Dillon wrote:

Looks like xbean-naming is still compiling for 1.4.  Is there any  
specific reason for this?  Can we switch all of xbean to compile  
for 1.5... and if you need 1.4 compat, then use the retrotranslator- 
maven-plugin's translate-project goal to make jdk14 artifacts?


--jason


On Mar 20, 2007, at 5:14 AM, David Jencks wrote:


geronimo-naming jar

I think you'll find you need to update xbean-naming.

thanks
david jencks
On Mar 20, 2007, at 4:03 AM, Jason Dillon wrote:

The server/trunk build is picking this up in configs/rmi- 
naming... but from where?


Need to update this to use java.util.concurrent... its using  
backport-concurrent-util at the moment.


--jason

Re: What is this doing here modules/geronimo-openejb-builder/geronimo-openejb.xml

[Dain Sundstrom]

It is used when testing the openejb itests in G.  This testing is  
done by hand and there isn't any where really better for it.


-dain

On Mar 19, 2007, at 4:00 PM, Jason Dillon wrote:


Anyone know?

--jason

Re: Weeding out backport-util-concurrent

[Dain Sundstrom]

On Mar 19, 2007, at 2:44 PM, Jason Dillon wrote:

Now that server/trunk requires 1.5 to build and run, I think we  
should start to weed out our usage of the backport-util-concurrent  
package (and concurrent if there is still anything left of that in  
our src tree).


I think we may still have to include backport-util-concurrent-*.jar  
in the assembly until all of our dependencies have weeded it out  
too... or perhaps just have to live with that in the repository.   
But hopefully we can remove our usage of these classes and not need  
to include this puppy in lib/* anymore.


Looks like we are currently using edu.emory.mathcs.backport in 39  
locations (based on imports) which are over 25 files.


 * * *

Anyone know of any reason why we shouldn't change all of these to  
use the java.util.concurrent.* classes?


Let's do it.

-dain

CMP 1.x functionally complete

[Dain Sundstrom]

For those of you that aren't subscribed to the OpenEJB dev list... I  
just committed support for CMP 1.x complex and unknown primary keys  
which were the two small remaining features for 1.x.


Tomorrow, I'm going to start on the remaining 2.x features which are  
complex and unknown primary keys in relationships and support for  
ejbSelect methods.


Please note, this does not mean that these functions are certified  
compliant, just fully implemented.


-dain

Re: SAAJ integration idea

[Dain Sundstrom]

On Mar 14, 2007, at 10:40 AM, Jarek Gawor wrote:


> Another idea I've had was to create a new context classloader (when
> set() is called) instead of the thread local solution. That new
> context classloader would first load a specific jar file for the  
SAAJ

> implementation (the jar file would just contain SAAJ configuration
> files) and delegate everything else to the existing context
> classloader. That way, since the right configuration files would
> appear first in the classloader, it would force the right SAAJ
> implementation to be used (the SAAJ factory classes first check the
> context classloader for the configuration files).

I don't see how this could work as the resource data would likely be
cached by Java code, so when you attempt switch to another SAAJ
implementation the Java code won't notice the CL switch.


Hmm... you mean that information would be cached somewhere else
besides the classloader?


Sure.  Resource files are just byte arrays, and some code will read  
them in and interpret them.  Normally, this type of code caches the  
results since disks are so slow.  Maybe we are talking about  
different things.


-dain

[jira] Created: (GERONIMO-2969) Transaction recovery broken for MDBs

[Dain Sundstrom (JIRA)]

Transaction recovery broken for MDBs


 Key: GERONIMO-2969
 URL: https://issues.apache.org/jira/browse/GERONIMO-2969
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: connector, OpenEJB
Reporter: Dain Sundstrom


Transaction recovery for MDBs is not currently working because the OpenEJB 
MdbContainer does not register the XAResources from an ActivationSpec with the 
Geronimo transaction manager.  This means that Geronimo has no resource name to 
write in to the transaction recovery log.

I commented out the code in the HowlLog that enforces a registered name to the 
MDB container will function, but the recover process will not work.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: MDBs working in 2.0

[Dain Sundstrom]

On Mar 14, 2007, at 5:46 AM, Kevan Miller wrote:



On Mar 14, 2007, at 3:53 AM, Dain Sundstrom wrote:

I believe that I have MDBs working in 2.0 (and the tck).  In  
general they should work about as well as Stateless beans do, but  
haven't received as much testing.


That's great. Nice stuff.



I also believe I have broken transaction recovery for the time being.


K. Did you create a Jira so that we can keep track of this? Don't  
want it to be forgotten... Some information on how it's broken  
would be helpful.


GERONIMO-2969

-dain

Re: SAAJ integration idea

[Dain Sundstrom]

On Mar 14, 2007, at 8:15 AM, Jarek Gawor wrote:


I'm working on the SAAJ integration in Geronimo. I have the following
idea on how to integrate it and I would applicate any comments,
suggestions, better solutions, etc.

We have three different SAAJ implementations to work with: Axis1,
Axis2, and Sun. And we can't really just use one as Axis1/Axis2 expect
their own implementations. Also, please keep in mind that within the
same module we can have both JAX-RPC and JAX-WS web services.
Now, in G code in certain places we know exactly what sort of SAAJ
implementation should be used. For example, if I'm invoking a Axis2
service, it should be using Axis2 SAAJ implementation. Or if I'm
calling a JAX-RPC service (using service-ref) Axis1 SAAJ
implementation should be used, and so on. So the idea is this:

First, in such places that we know what implementation should be used,
set the SAAJ implementation preference explicitly. For example:

SAAJUniverse universe = new SAAJUniverse(SAAJUniverse.Axis1);
universe.set();
try {
 // invoke the web service
} finally {
 universe.unset();
}

The .set() method would set some thread local variable with the SAAJ
implementation preference.


If a webservice can call another webservice locally (using the same  
thread), you will need to keep the original thread local value and  
reset it on the way out.



Second, we would provide our own implementations of the different SAAJ
Factory classes. These factory classes would just check that thread
local preference variable and return the appropriate factory instance.
Or if no preference is set, default to Sun's implementation.


Do all the SAAJ implementations implement the same spec API version?   
If not you will not be able to switch implementations like this.



Just to clarify, the user is not expected to do the SAAJUniverse
set/unset bit. Only the web service container implementations or
service-ref builders would do that (i.e. the idea is to make it
transparent to the user as much as possible).

Also, if a call is made within some SAAJ universe but then it is
handled by some thread pool later on, things might break. So this
solution is definitely not foolproof but hopefully good enough.


It should work as long as you reset the thread local in a finally  
block as you have above.



Another idea I've had was to create a new context classloader (when
set() is called) instead of the thread local solution. That new
context classloader would first load a specific jar file for the SAAJ
implementation (the jar file would just contain SAAJ configuration
files) and delegate everything else to the existing context
classloader. That way, since the right configuration files would
appear first in the classloader, it would force the right SAAJ
implementation to be used (the SAAJ factory classes first check the
context classloader for the configuration files).


I don't see how this could work as the resource data would likely be  
cached by Java code, so when you attempt switch to another SAAJ  
implementation the Java code won't notice the CL switch.



Thoughts?


I was worried that we would have to force all WS stacks to a common  
SAAJ implementation, but this may just work.


-dain

MDBs working in 2.0

[Dain Sundstrom]

I believe that I have MDBs working in 2.0 (and the tck).  In general  
they should work about as well as Stateless beans do, but haven't  
received as much testing.


I also believe I have broken transaction recovery for the time being.

-dain

Re: [VOTE] Release geronimo-javamail_1.3.1_mail-1-1 and geronimo-javamail_1.3.1_provider-1.1

[Dain Sundstrom]

+1

dain

On Mar 12, 2007, at 2:54 AM, Rick McGuire wrote:

This is a vote for release of a new version of the geronimo- 
javamail_1.3.1_mail and geronimo-javamail_1.3.1_provider jars.   
These are companions to the recently released version of the  
javamail 1.3.1 spec jar.  The provider jar contains the provider  
portion of a fix to SMTPTransport.send() that was included in the  
javamail spec release.  The mail jar is a merged jar containing the  
latest of both the javamail spec and javamail provider code.  The  
Geronimo 1.2 release is dependent upon both the spec jar and the  
provider jar.


[ ] +1 release the new binaries
[ ] 0 no opinion
[ ] -1 do not release the new binaries


I hereby propose we release this branch and it's binaries as final.

Release Branch:  https://svn.apache.org/repos/asf/geronimo/javamail/ 
branches/geronimo-javamail_1.3.1-1.1

Build Binaries:  http://people.apache.org/~rickmcguire/stage-javamail/

Here's my +1

Rick

Re: svn commit: r517486 - in /geronimo/server/trunk: configs/openejb/src/plan/ modules/geronimo-connector-builder/src/main/java/org/apache/geronimo/connector/deployment/ modules/geronimo-connector/src

[Dain Sundstrom]

Sorry... completely missed this message...

On Mar 12, 2007, at 7:27 PM, David Jencks wrote:

Is there some reason you didn't use the activationSpecInfo map  
which already had the info you put into  
messageListenerToActivationSpec map and a lot more besides?


Well, I can't say I'm totally happy with my solution but it does  
work.  The reason I put that data into the ResourceAdapterWrapper was  
because I couldn't figure out how to reliably pick all the data I  
needed out of the GBean objects.  There are quite a few objects and  
not everything is linked or had a dependency.  This means I have to  
listen for multiple GBeans and keep everything in sync.  It was  
simply easier to copy the data into the RA.


I prefer to put this info in the ResourceAdapterModuleimpl which  
represents the rar file rather than the ResourceAdapterWrapper  
which represents an individual instance of a resource adapter  
specified by the rar file to avoid duplication, but it doesn't make  
a lot of difference.


That would be fine with me as long as I can call ra.getModule 
().getMessageListenerToActivationSpecMap() (or a shorter name) and  
have it work every time.


At some point we should make it so only one copy of this data is  
stuffed into gbeans, whether it's the simplified data you have or  
the fuller representation I had, and take it out of whatever gbeans  
aren't being used.


I'm cool with any changes... I just want to get it working and then  
we can refactor later.


-dain

[jira] Created: (GERONIMO-2959) PersistenceUnitRefBuilder does not create unique enough name queries

[Dain Sundstrom (JIRA)]

PersistenceUnitRefBuilder does not create unique enough name queries


 Key: GERONIMO-2959
 URL: https://issues.apache.org/jira/browse/GERONIMO-2959
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: naming
Reporter: Dain Sundstrom
 Assigned To: David Jencks


PersistenceUnitRefBuilder creates abstract name queries like 
?name=cmp#org.apache.geronimo.persistence.PersistenceUnitGBean which is not 
unique enough to differentiate persistence units with overlapping names from 
different persistence modules.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Getting ready for G 1.2 release?

[Dain Sundstrom]

The openejb release is dependent on the yoko release.  As soon as  
yoko is ready, we'll start the release.


-dain

On Mar 8, 2007, at 6:43 PM, Jason Dillon wrote:

I think we should start wrapping up the SNAPSHOT deps we have in  
1.2 to prepare for a release.  These are the ones I am aware of:


openejb 2.3-incubating-SNAPSHOT
yoko 1.0-incubating-M2-SNAPSHOT
activemq 4.1-SNAPSHOT

ActiveMQ is on its way to releasing 4.1.1, which should be  
available soonish (maybe sometime next week?).


When can we get non-SNAPSHOT artifacts from OpenEJB and Yoko?

 * * *

There are also a few SNAPSHOT artifacts configured in  the  
testsuite/*:


maven-invoker-plugin 1.0-SNAPSHOT
maven-surefire-plugin 2.8-SNAPSHOT

We don't even use the maven-invoker-plugin, so that can be  
dropped.  And the maven-surefire-plugin is for TestNG support, and  
there isn't much hope of getting that resolved any time soon.  But,  
these don't need to be non-SNAPSHOT's for the release (would be  
nice though) since this module is not included in the default build.


I suppose we could include the maven-surefire-plugin 2.8-SNAPSHOT  
(and its deps) in the repository module (using timestamp-build  
versions).  But IMO its not a requirement or blocking issue for 1.2  
releasability.


 * * *

There are also 8 unresolved JIRA's for 1.2:

https://issues.apache.org/jira/secure/IssueNavigator.jspa? 
reset=true&mode=hide&sorter/order=DESC&sorter/ 
field=priority&resolution=-1&pid=10220&fixfor=12310181


Anyone know of any other issues which need to be wrapped up for  
1.2?  And/or if any of the above issues should be resolved/deferred  
for another release?  If you have a moment, please take a peek.


--jason

Re: Getting ready for G 1.2 release?

[Dain Sundstrom]

David,

If you want to fix these, that is cool.  Otherwise, they can get  
fixed in a point release.


-dain

On Mar 8, 2007, at 7:47 PM, David Jencks wrote:


I think the yoko release is on the way if not out.

Jiras && my opinion:

GERONIMO-433 Tolerate non-Sun JREs
has anyone tried this? with yoko it ought to work

Patch Available  	 GERONIMO-2289  	 GeronimoAsMavenServlet.java  
generates wrong default-repository element

No idea

GERONIMO-2697OpenEJB schemas missing in Geronimo 1.2 distribution
we should fix this.  Should be a 1 line change in some pom.

GERONIMO-2672  	 Improving the Deployment schema documentation - 
geronimo-application.xsd

no idea

GERONIMO-2818  	 In-Place deployment does not interpret Manifest  
Class-Path entries correctly in JAR files
I'd guess this is easy if someone can figure out what's going  
wrong, would be good to fix


GERONIMO-2918  	 Have the ActiveMQ broker configured from an  
external configuration file by default
I'm not sure this is such a great idea, but I'm not sure.  Actually  
I wonder about making an amq config builder that can read these  
files natively (and also gbeans etc).  This is probably too much  
for 1.2.


GERONIMO-2927  	 Cannot rebuild Geronimo with external ActiveMQ  
XBean configuration because Spring Framework is missing
This seems pretty important.  I think this involves adding spring  
to the amq-broker config and hiding it in the amq config, a couple  
minutes + testing.


thanks
david jencks


On Mar 8, 2007, at 9:43 PM, Jason Dillon wrote:

I think we should start wrapping up the SNAPSHOT deps we have in  
1.2 to prepare for a release.  These are the ones I am aware of:


openejb 2.3-incubating-SNAPSHOT
yoko 1.0-incubating-M2-SNAPSHOT
activemq 4.1-SNAPSHOT

ActiveMQ is on its way to releasing 4.1.1, which should be  
available soonish (maybe sometime next week?).


When can we get non-SNAPSHOT artifacts from OpenEJB and Yoko?

 * * *

There are also a few SNAPSHOT artifacts configured in  the  
testsuite/*:


maven-invoker-plugin 1.0-SNAPSHOT
maven-surefire-plugin 2.8-SNAPSHOT

We don't even use the maven-invoker-plugin, so that can be  
dropped.  And the maven-surefire-plugin is for TestNG support, and  
there isn't much hope of getting that resolved any time soon.   
But, these don't need to be non-SNAPSHOT's for the release (would  
be nice though) since this module is not included in the default  
build.


I suppose we could include the maven-surefire-plugin 2.8-SNAPSHOT  
(and its deps) in the repository module (using timestamp-build  
versions).  But IMO its not a requirement or blocking issue for  
1.2 releasability.


 * * *

There are also 8 unresolved JIRA's for 1.2:

https://issues.apache.org/jira/secure/IssueNavigator.jspa? 
reset=true&mode=hide&sorter/order=DESC&sorter/ 
field=priority&resolution=-1&pid=10220&fixfor=12310181


Anyone know of any other issues which need to be wrapped up for  
1.2?  And/or if any of the above issues should be resolved/ 
deferred for another release?  If you have a moment, please take a  
peek.


--jason

Re: Problem with svn head, TagLibConfiguration, xerces, and jdk 1.5 (in geronimo)

[Dain Sundstrom]

When we've had problems like this before, we passed the offending  
library with an unclosable stream.


-dain

On Mar 7, 2007, at 1:29 PM, David Jencks wrote:

I'm trying to run svn head inside the geronimo integration and ran  
into a bizarre problem (yet again, see below) in which xerces is  
closing a JarUrlStream which closes the entire ZipFile thus  
preventing any further access to the jar file.  Going back to 6.1.0  
fixes the problem.


The relevant part of the stacktraces I get look like:

java.lang.IllegalStateException: zip file closed
at java.util.zip.ZipFile.ensureOpen(ZipFile.java:518)
at java.util.zip.ZipFile.getInputStream(ZipFile.java:300)
at java.util.zip.ZipFile.getInputStream(ZipFile.java:286)
at java.util.jar.JarFile.getInputStream(JarFile.java:387)
at sun.net.www.protocol.jar.JarURLConnection.getInputStream 
(JarURLConnection.java:136)
at org.mortbay.resource.URLResource.getInputStream 
(URLResource.java:206)
at org.mortbay.resource.JarResource.getInputStream 
(JarResource.java:106)
at  
org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp 
(TagLibConfiguration.java:189)
at org.mortbay.jetty.webapp.WebAppContext.startContext 
(WebAppContext.java:1171)
at org.mortbay.jetty.handler.ContextHandler.doStart 
(ContextHandler.java:501)
at org.mortbay.jetty.webapp.WebAppContext.doStart 
(WebAppContext.java:444)



Putting a breakpoing on ZipFile.close() I found that xerxes (I  
think the one in the apple 1.5.0_07 vm) is calling the close method  
when it's just trying to close an input stream from a jar entry.


I ran across this problem a couple years ago and solved it with an  
UnclosableInputStream that ignored close calls, but I don't quite  
see how to apply such a solution here.  Before I spend more time  
looking I wonder if anyone else has seen anything like this and  
might have advice on a solution.


thanks
david jencks

Re: [VOTE] Release geronimo-javamail_2.4_spec-1.3

[Dain Sundstrom]

+1

-dain

On Mar 5, 2007, at 5:08 AM, Rick McGuire wrote:

All, the javamail 1.3 spec has been updated to fix a problem with  
Transport.send() that multiple 1.1.1 and 1.2 beta users have  
tripped over.  We'd like to get this released in time for the  
Geronimo 1.2 final version so fewer people will be seeing this  
problem.


I hereby propose we release this branch and it's binaries as final.

Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ 
branches/geronimo-javamail_1.3.1_spec-1.3
Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ 
apache/geronimo/specs/geronimo-javamail_1.3.1_spec/1.3/



Here's my +1

Rick

Re: [BUILD] TRUNK: Failed for Revision: 514904

[Dain Sundstrom]

I had this same problem earlier today, but it went away with a rebuild.

-dain

On Mar 5, 2007, at 3:19 PM, [EMAIL PROTECTED] wrote:


Building with Maven version: 2.0.5
Revision: 514904 built with tests skipped
See the full build-1800.log file at http://people.apache.org/ 
~prasad/binaries/20070305/build-1800.log


[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]  
-- 
--

[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/prasad/geronimo/trunk/configs/persistence- 
jpa10-deployer/target/classes/META-INF
[INFO] Copying 2 files to /home/prasad/geronimo/trunk/configs/ 
persistence-jpa10-deployer/target/classes/META-INF

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /home/prasad/geronimo/trunk/configs/persistence- 
jpa10-deployer/target/plan/plan.xml

[INFO] [car:package]
[INFO] Packaging module configuration: /home/prasad/geronimo/trunk/ 
configs/persistence-jpa10-deployer/target/plan/plan.xml
[INFO] snapshot org.apache.geronimo.modules:geronimo-persistence- 
jpa10-builder:2.0-SNAPSHOT: checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-persistence- 
jpa10-builder:2.0-SNAPSHOT: checking for updates from axis2-m2-repo
[INFO] snapshot org.apache.geronimo.modules:geronimo-persistence- 
jpa10-builder:2.0-SNAPSHOT: checking for updates from codehaus- 
snapshots
[INFO] snapshot org.apache.geronimo.modules:geronimo-persistence- 
jpa10-builder:2.0-SNAPSHOT: checking for updates from apache.snapshots
[INFO] Building jar: /home/prasad/geronimo/trunk/configs/ 
persistence-jpa10-deployer/target/persistence-jpa10-deployer-2.0- 
SNAPSHOT.car

[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: persistence-jpa10-deployer-2.0- 
SNAPSHOT.car

[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/configs/persistence- 
jpa10-deployer/target/persistence-jpa10-deployer-2.0-SNAPSHOT.car  
to /home/prasad/.m2/repository/org/apache/geronimo/configs/ 
persistence-jpa10-deployer/2.0-SNAPSHOT/persistence-jpa10- 
deployer-2.0-SNAPSHOT.car
[INFO]  
-- 
--

[INFO] Building Geronimo Configs :: OpenJPA with dependencies
[INFO]task-segment: [install]
[INFO]  
-- 
--

[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/prasad/geronimo/trunk/configs/openjpa/ 
target/classes/META-INF
[INFO] Copying 2 files to /home/prasad/geronimo/trunk/configs/ 
openjpa/target/classes/META-INF

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /home/prasad/geronimo/trunk/configs/openjpa/ 
target/plan/plan.xml
Downloading: http://tomcat.apache.org/dev/dist/m2-repository//org/ 
apache/openjpa/openjpa-all/0.9.6-incubating/openjpa-all-0.9.6- 
incubating.pom
[WARNING] Unable to get resource 'org.apache.openjpa:openjpa- 
all:pom:0.9.6-incubating' from repository tomcat-m2-repo (http:// 
tomcat.apache.org/dev/dist/m2-repository/)
Downloading: http://ws.zones.apache.org/repository2//org/apache/ 
openjpa/openjpa-all/0.9.6-incubating/openjpa-all-0.9.6-incubating.pom
[WARNING] Unable to get resource 'org.apache.openjpa:openjpa- 
all:pom:0.9.6-incubating' from repository axis2-m2-repo (http:// 
ws.zones.apache.org/repository2/)
Downloading: http://people.apache.org/repo/m2-incubating- 
repository//org/apache/openjpa/openjpa-all/0.9.6-incubating/openjpa- 
all-0.9.6-incubating.pom

3K downloaded
Downloading: http://tomcat.apache.org/dev/dist/m2-repository//org/ 
apache/openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa- 
xmlstore-0.9.6-incubating.pom
[WARNING] Unable to get resource 'org.apache.openjpa:openjpa- 
xmlstore:pom:0.9.6-incubating' from repository tomcat-m2-repo  
(http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading: http://ws.zones.apache.org/repository2//org/apache/ 
openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa-xmlstore-0.9.6- 
incubating.pom
[WARNING] Unable to get resource 'org.apache.openjpa:openjpa- 
xmlstore:pom:0.9.6-incubating' from repository axis2-m2-repo  
(http://ws.zones.apache.org/repository2/)
Downloading: http://people.apache.org/repo/m2-incubating- 
repository//org/apache/openjpa/openjpa-xmlstore/0.9.6-incubating/ 
openjpa-xmlstore-0.9.6-incubating.pom

1K downloaded
Downloading: http://tomcat.apache.org/dev/dist/m2-repository//org/ 
apache/geronimo/specs/geronimo-j2ee-connector_1.5_spec/1.0.1/ 
geronimo-j2ee-connector_1.5_spec-1.0.1.jar
[WARNING] Unable to get resource  
'org.ap

Re: 2.0-M3 Download page update

[Dain Sundstrom]

On Mar 5, 2007, at 11:53 AM, Matt Hogstrom wrote:

I'm seeing the following message being issued for Tomcat and Jetty  
for the tar image:


tar: A lone zero block at 158322 for Jetty, and

tar: A lone zero block at 158480 for Tomcat.

The servers work correctly AFAICT but this is odd.  I'll see if I  
can isolate the problem.


The tar command in Maven causes that.  The only way I know around  
this problem is to retar the packages using a command line tool.


-dain

Re: Jars in the dist

[Dain Sundstrom]

On Mar 2, 2007, at 1:22 PM, Jason Dillon wrote:


On Mar 2, 2007, at 1:17 PM, Davanum Srinivas wrote:

Team,

#1) 2 versions of castor jar are present. Do we even need castor jar?

castor-0.9.5.3.jar
castor-1.0.5.jar


I hope we can use the newer... never tried to see if that works or  
not though...


OpenEJB uses castor to load two files still.  OpenEJB is using  
version 1.0.5.


-dain

Re: mx4j dependencies

[Dain Sundstrom]

On Mar 1, 2007, at 1:32 PM, Jason Dillon wrote:

 * modules/geronimo-jetty6/src/test/java/org/apache/geronimo/jetty6/ 
ClassLoaderTest.java (attempts to use "mx4j.MBeanDescription" to  
test classloading stuff)


Not sure what to do about the later... or even if anything needs to  
be done.


I'd just say remove the test.

-dain