Re: [VOTE] release YOKO 1.2 - 1st attempt.

[viola lu]

+1

On Wed, Jul 13, 2011 at 12:38 PM, Kevan Miller wrote:

> Same about the year in the NOTICE file. So, would like to see that updated.
>
> The source, signatures/checksums, LICENSE/NOTICE file looks good. I'm
> running a build, now. Will let you know if I see any problems. I keep
> building while a Geronimo server is running. IIRC, the server interferes
> with the junit tests.
>
> Once the NOTICE file is updated, I should be +1
>
> --kevan
>
> On Jul 12, 2011, at 11:45 AM, Forrest Xia wrote:
>
> > [VOTE] release YOKO 1.2 - 1st attempt.
> >
> > This is a bug fixes release for Java EE 6 compliance:
> >
> > The fixes in this release are:
> > YOKO-431 Classloader issue when initializing a corba skeleton for EJB
> object
> > YOKO-433 YOKO chunking logic does not set the the chunk flag to false
> when the valuetype tag is false on the chunking bit
> >
> > The artifacts up for vote are:
> > 1.
> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz
> > 2.
> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip
> >
> > The staging repository is:
> > https://repository.apache.org/content/repositories/orgapachegeronimo-016
> >
> > The source tag is:
> > https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/
> >
> >  Vote will be open for 72 hours.
> >
> >  [ ] +1  approve
> >  [ ] +0  no opinion
> >  [ ] -1  disapprove (and reason why)
> >
> > --
> > Shawn
>
>


-- 
viola

Apache Geronimo

Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

[Shawn Jiang]

OK,  for this spec,  let's leave it as is. I'll update the remaining
bundles before releasing them.

On Wed, Jul 13, 2011 at 12:34 PM, Kevan Miller wrote:

>
> On Jul 13, 2011, at 12:29 AM, Shawn Jiang wrote:
>
> >
> >
> > On Wed, Jul 13, 2011 at 12:01 PM, Kevan Miller 
> wrote:
> > Looks good with one exception.
> >
> > geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains:
> >
> > Copyright 2003-2006 The Apache Software Foundation
> >
> > Not a hard requirement, but by our convention the latter date should be
> 2011.
> >
> > Just updated latter date to 2011 for all notice files in geronimo
> bundles.
> >
> > Also, most of our LICENSE/NOTICE files no longer have the .txt suffix.
> >
> > Do you mean we need to rename LICENSE/NOTICE to LICENSE.txt/NOTICE.txt ?
>
> Yes.
>
> --kevan




-- 
Shawn

Re: [VOTE] release YOKO 1.2 - 1st attempt.

[Kevan Miller]

Same about the year in the NOTICE file. So, would like to see that updated.

The source, signatures/checksums, LICENSE/NOTICE file looks good. I'm running a 
build, now. Will let you know if I see any problems. I keep building while a 
Geronimo server is running. IIRC, the server interferes with the junit tests.

Once the NOTICE file is updated, I should be +1

--kevan

On Jul 12, 2011, at 11:45 AM, Forrest Xia wrote:

> [VOTE] release YOKO 1.2 - 1st attempt.
> 
> This is a bug fixes release for Java EE 6 compliance:
> 
> The fixes in this release are:
> YOKO-431 Classloader issue when initializing a corba skeleton for EJB object
> YOKO-433 YOKO chunking logic does not set the the chunk flag to false when 
> the valuetype tag is false on the chunking bit
> 
> The artifacts up for vote are:
> 1. 
> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz
> 2. 
> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip
> 
> The staging repository is:
> https://repository.apache.org/content/repositories/orgapachegeronimo-016
> 
> The source tag is:
> https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/
> 
>  Vote will be open for 72 hours.
> 
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
> 
> -- 
> Shawn

Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

[Kevan Miller]

On Jul 13, 2011, at 12:29 AM, Shawn Jiang wrote:

> 
> 
> On Wed, Jul 13, 2011 at 12:01 PM, Kevan Miller  wrote:
> Looks good with one exception.
> 
> geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains:
> 
> Copyright 2003-2006 The Apache Software Foundation
> 
> Not a hard requirement, but by our convention the latter date should be 2011.
> 
> Just updated latter date to 2011 for all notice files in geronimo bundles.
>  
> Also, most of our LICENSE/NOTICE files no longer have the .txt suffix.
> 
> Do you mean we need to rename LICENSE/NOTICE to LICENSE.txt/NOTICE.txt ?

Yes.

--kevan

Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

[Shawn Jiang]

On Wed, Jul 13, 2011 at 12:01 PM, Kevan Miller wrote:

> Looks good with one exception.
>
> geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains:
>
> Copyright 2003-2006 The Apache Software Foundation
>
> Not a hard requirement, but by our convention the latter date should be
> 2011.


Just updated latter date to 2011 for all notice files in geronimo bundles.


> Also, most of our LICENSE/NOTICE files no longer have the .txt suffix.


Do you mean we need to rename LICENSE/NOTICE to LICENSE.txt/NOTICE.txt ?



> Neither of these are a hard requirement. But given the number of releases
> that we'll have coming up, may as well cleanup now...
>
> Beyond the above, source, signatures/checksums, and build -- all look good
> to me. With the above minor concerns, I'm +0.
>
> --kevan
>
> On Jul 12, 2011, at 11:18 AM, Shawn Jiang wrote:
>
> > [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
> >
> > This is a bug fix release that only includes one bug fix for
> GERONIMO-5848
> >
> > The components up for vote are:
> >
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz
> >
> >
> > The staging repository is:
> >
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/
> >
> > The source repo is:
> >
> >
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/
> >
> >  Vote will be open for 72 hours.
> >
> >  [ ] +1  approve
> >  [ ] +0  no opinion
> >  [ ] -1  disapprove (and reason why)
> >
> > --
> > Shawn
>
>


-- 
Shawn

Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

[Kevan Miller]

Looks good with one exception.

geronimo-stax-api_1.2_spec-1.1/NOTICE.txt contains:

Copyright 2003-2006 The Apache Software Foundation

Not a hard requirement, but by our convention the latter date should be 2011. 
Also, most of our LICENSE/NOTICE files no longer have the .txt suffix. Neither 
of these are a hard requirement. But given the number of releases that we'll 
have coming up, may as well cleanup now...

Beyond the above, source, signatures/checksums, and build -- all look good to 
me. With the above minor concerns, I'm +0.

--kevan

On Jul 12, 2011, at 11:18 AM, Shawn Jiang wrote:

> [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
> 
> This is a bug fix release that only includes one bug fix for GERONIMO-5848
> 
> The components up for vote are:
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz
> 
> 
> The staging repository is:
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/
> 
> The source repo is:
> 
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/
> 
>  Vote will be open for 72 hours.
> 
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
> 
> -- 
> Shawn

Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

[Ivan]

+1

2011/7/13 Forrest Xia 

> Build and rat check seems OK for me
>
> +1
>
> Forrest
>
>
> On Tue, Jul 12, 2011 at 11:22 PM, Shawn Jiang  wrote:
>
>> 1, "mvn install" build is OK
>> 2, "mvn rat:check" result is clean.
>>
>> Again, Here is my own +1.
>>
>> On Tue, Jul 12, 2011 at 11:18 PM, Shawn Jiang wrote:
>>
>>> [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
>>>
>>> This is a bug fix release that only includes one bug fix for
>>> GERONIMO-5848
>>>
>>> The components up for vote are:
>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
>>>
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz
>>>
>>>
>>> The staging repository is:
>>>
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-019/
>>>
>>> The source repo is:
>>>
>>>
>>> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/
>>>
>>>  Vote will be open for 72 hours.
>>>
>>>  [ ] +1  approve
>>>  [ ] +0  no opinion
>>>  [ ] -1  disapprove (and reason why)
>>>
>>> --
>>> Shawn
>>>
>>
>>
>>
>> --
>> Shawn
>>
>
>


-- 
Ivan

Re: [VOTE] release YOKO 1.2 - 1st attempt.

[Shawn Jiang]

build OK for me.

+ 1 if interop TCK 100% pass

On Tue, Jul 12, 2011 at 11:57 PM, Forrest Xia  wrote:

> 1. mvn test, all passed
> 2. mvn install, all succeed
> 3. mvn rat:check, except those auto-generated CORBA spec classes and OMG
> copyright files, all of the other files are passed!
>
> So, My +1
>
> Forrest
>
>
> On Tue, Jul 12, 2011 at 11:45 PM, Forrest Xia  wrote:
>
>> [VOTE] release YOKO 1.2 - 1st attempt.
>>
>> This is a bug fixes release for Java EE 6 compliance:
>>
>> The fixes in this release are:
>> YOKO-431 Classloader issue when initializing a corba skeleton for EJB
>> object
>> YOKO-433 YOKO chunking logic does not set the the chunk flag to false when
>> the valuetype tag is false on the chunking bit
>>
>> The artifacts up for vote are:
>> 1.
>> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz
>> 2.
>> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip
>>
>> The staging repository is:
>>
>> 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-016
>>
>> The source tag is:
>> https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/
>>
>>  Vote will be open for 72 hours.
>>
>>  [ ] +1  approve
>>  [ ] +0  no opinion
>>  [ ] -1  disapprove (and reason why)
>>
>> --
>> Shawn
>
>
>


-- 
Shawn

Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

[Forrest Xia]

Build and rat check seems OK for me

+1

Forrest

On Tue, Jul 12, 2011 at 11:22 PM, Shawn Jiang  wrote:

> 1, "mvn install" build is OK
> 2, "mvn rat:check" result is clean.
>
> Again, Here is my own +1.
>
> On Tue, Jul 12, 2011 at 11:18 PM, Shawn Jiang  wrote:
>
>> [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
>>
>> This is a bug fix release that only includes one bug fix for GERONIMO-5848
>>
>> The components up for vote are:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
>>
>> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz
>>
>>
>> The staging repository is:
>>
>> https://repository.apache.org/content/repositories/orgapachegeronimo-019/
>>
>> The source repo is:
>>
>>
>> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/
>>
>>  Vote will be open for 72 hours.
>>
>>  [ ] +1  approve
>>  [ ] +0  no opinion
>>  [ ] -1  disapprove (and reason why)
>>
>> --
>> Shawn
>>
>
>
>
> --
> Shawn
>

Re: Is there possible for 1.7.0 release ?

[Ivan]

Hi, devs, I just uploaded a patch for
AXIS2-5023.
If possible, please help to review it first, as I am not quite confident for
the changes for this jira, although it seems to work now.
Thanks.

2011/7/12 Ivan 

> OK, I forget to reply to Axis2 mail list again ...
>
>
> 2011/7/12 Ivan 
>
>>
>>
>> 2011/7/12 Andreas Veithen 
>>
>>> The changes for Neethi 3.0.x (including the three changes mentioned in
>>> your mail) should now be included in the latest 1.6.1-SNAPSHOT build.
>>> The release vote for Neethi 3.0.1 has started a couple of hours ago.
>>> Once that release is complete, we can switch to the Neethi 3.0.1
>>> release version on the 1.6 branch and Axis2 1.6.1 will be ready for
>>> release.
>>>
>>>Thanks, Andreas, I will try to switch to Axis2 1.6.1-SNAPSHOT soon.
>>
>>
>>> Regarding the list of JIRA issues, if I understand this correctly, the
>>> Geronimo project has a sort of patching mechanism so that they are not
>>> on the critical path for the Geronimo release, which means that we
>>> have the time to review them properly and first apply them to the
>>> trunk, without delaying any Geronimo release. Can you confirm this?
>>>
>>
>>Hmm, I would say that the patching mechanism used now is somewhat a
>> 'temporary' solution, and it is not expected to do that. Geronimo needs to
>> bundle the axis2 components, that gave us a chance to modify codes.
>>We do hope that those patches could be reviewed and included in Axis2
>> code base. And yes, they work well now,  but it is better to have your Axis2
>> experts' view for them. Also, from other sides, most of them are related to
>> JAX-WS 2.2 support. I guess that they are also important for Axis2 ;-)
>>Anyway, it depends on your schedule, and your guys really helped us a
>> lot in the past.
>>Thanks.
>>
>>>
>>> Andreas
>>>
>>> On Sun, Jul 10, 2011 at 15:58, Ivan  wrote:
>>> > Hi, Axis2 devs, any thought to port those listed changes to 1.6 branch
>>> ?
>>> > Thanks.
>>> >
>>> > 2011/7/8 Ivan 
>>> >>
>>> >> Just add the geronimo mail address.
>>> >>
>>> >> 2011/7/8 Ivan 
>>> >>>
>>> >>> Hi, the initial reason for moving to 1.7.0-SNAPSHOT is for the Policy
>>> >>> support, the changes are list below. If they could be ported to 1.6
>>> branch,
>>> >>> we are fine to try to turn to 1.6 branch.
>>> >>> Also, understand that you guys are busy with some other stuffs, will
>>> be
>>> >>> very appreciated if those web services patches could be reviewed and
>>> >>> included in the 1.6 branch.  I pasted the Jira list in the end of the
>>> mail.
>>> >>> The initial thread could be found
>>> >>> http://www.mail-archive.com/java-dev@axis.apache.org/msg06438.html
>>> >>> Thanks.
>>> >>> --->
>>> >>> Revision: 1090457
>>> >>> Author: veithen
>>> >>> Date: 5:36:59 AM, Saturday, April 09, 2011
>>> >>> Message:
>>> >>> Exclude the transitive Woodstox dependency from Neethi. Otherwise we
>>> will
>>> >>> end up with two versions of Woodstox.
>>> >>> 
>>> >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml
>>> >>> Revision: 1090429
>>> >>> Author: veithen
>>> >>> Date: 4:19:38 AM, Saturday, April 09, 2011
>>> >>> Message:
>>> >>> Neethi now supports DOM elements. Therefore we don't need to convert
>>> DOM
>>> >>> elements to stream any more. Alos, DOM2Writer seems to have a bug
>>> that
>>> >>> causes processing of some policies to fail.
>>> >>> 
>>> >>> Modified :
>>> >>>
>>> /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java
>>> >>> Revision: 1089989
>>> >>> Author: veithen
>>> >>> Date: 4:27:37 AM, Friday, April 08, 2011
>>> >>> Message:
>>> >>> Updated Neethi dependency and fixed PolicyUtil such that it supports
>>> all
>>> >>> WS-Policy namespaces supported by Neethi.
>>> >>> 
>>> >>> Modified :
>>> >>>
>>> /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java
>>> >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml
>>> >>> <---
>>> >>> Jira list:
>>> >>> (AXIS2-5062) Connection is not released while using JAXWS
>>> client
>>> >>> API
>>> >>> (AXIS2-5039) Override the SOAPAction from the SOAPMessage MIME header
>>> if
>>> >>> it is explicitly configured later
>>> >>> (AXIS2-5023) Ambigious use of isElementData in the Block interface
>>> >>> (AXIS2-5022) Support addressing meta data with policy 1.5 framework
>>> >>> (AXIS2-5040) Ignore the methods while no webmethod annotation and no
>>> >>> webservice annotation on the declaring class
>>> >>> (AXIS2-5034) Incorrect exception name is used for fault message while
>>> >>> creating AxisService from WSDL
>>> >>> (AXIS2-5001) SOAPMessage.getSOAPHeaders() return null while no
>>> headers in
>>> >>> the soap envelope
>>> >>> (AXIS2-4996) Exclude content-length header while chunked is enabled
>>> >>> 2011/7/8 Andreas Veithen 
>>> 
>>>  Ivan,
>>> 
>>>  There are no plans for a 1.7.0 release, but we can do a 1.6.1
>>>  maintenance relea

[jira] [Created] (GERONIMO-6073) Rotation and appending of console output when Geronimo is run a windows service

[Vamsavardhana Reddy (JIRA)]

Rotation and appending of console output when Geronimo is run a windows service
---

 Key: GERONIMO-6073
 URL: https://issues.apache.org/jira/browse/GERONIMO-6073
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: commands
Affects Versions: 2.2.1, 2.1.7
 Environment: Windows
Reporter: Vamsavardhana Reddy


GERONIMO-4394 provided for running Geronimo as windows service.  The console 
output STDOUT is directed to geronimosrv.out and STDERR is directed to 
geronimosrv.err.  If the server is running for long, these files can grow big 
requiring the server to be stopped.  Also, each time the server is started as 
service, the files from the previous run are overwritten since the output does 
not get appended to existing file.  So, if a user is interested in the console 
output from the previous runs, it is lost.  So, console output rotation and 
appending to already existing files should be a good improvement for the "Run 
Geronimo as a Windows service" feature.

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

Re: [VOTE] release YOKO 1.2 - 1st attempt.

[Forrest Xia]

1. mvn test, all passed
2. mvn install, all succeed
3. mvn rat:check, except those auto-generated CORBA spec classes and OMG
copyright files, all of the other files are passed!

So, My +1

Forrest

On Tue, Jul 12, 2011 at 11:45 PM, Forrest Xia  wrote:

> [VOTE] release YOKO 1.2 - 1st attempt.
>
> This is a bug fixes release for Java EE 6 compliance:
>
> The fixes in this release are:
> YOKO-431 Classloader issue when initializing a corba skeleton for EJB
> object
> YOKO-433 YOKO chunking logic does not set the the chunk flag to false when
> the valuetype tag is false on the chunking bit
>
> The artifacts up for vote are:
> 1.
> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz
> 2.
> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip
>
> The staging repository is:
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-016
>
> The source tag is:
> https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/
>
>  Vote will be open for 72 hours.
>
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
>
> --
> Shawn

[VOTE] release YOKO 1.2 - 1st attempt.

[Forrest Xia]

[VOTE] release YOKO 1.2 - 1st attempt.

This is a bug fixes release for Java EE 6 compliance:

The fixes in this release are:
YOKO-431 Classloader issue when initializing a corba skeleton for EJB object
YOKO-433 YOKO chunking logic does not set the the chunk flag to false when
the valuetype tag is false on the chunking bit

The artifacts up for vote are:
1.
https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz
2.
https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip

The staging repository is:

https://repository.apache.org/content/repositories/orgapachegeronimo-016

The source tag is:
https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/

 Vote will be open for 72 hours.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

-- 
Shawn

Re: Class-Path in manifest file of applicationclient module.

[Ivan]

>From the word of 'library', I do not think that ejb module is belong to this
scope.

2011/7/12 Shawn Jiang 

> Components in the application client container must have access to the
> following
> classes and resources.
> • The content of the application client jar file.
> • The transitive closure of any libraries referenced by the above jar file
> (as spec-
> ified in Section EE.8.2, “Library Support”).
>
>
>
>
> On Tue, Jul 12, 2011 at 11:10 PM, Ivan  wrote:
>
>> Hmm, I double checked the spec, so which rule should cover this request ?
>>
>> --->
>> • The Java EE API classes specified in Table EE.6-1 for the containers
>> other than
>> the application client container.
>> • Any installed libraries available in the application server.
>> • Other classes or resources contained in the application package, and
>> specified
>> by an explicit use of an extension not defined by this specification.
>> • Other classes and resources that are part of the implementation of the
>> applica-
>> tion server.
>> <---
>>
>>
>> 2011/7/12 Shawn Jiang 
>>
>>> per java ee 6 spec:   EE.8.3.3 Application Client Container Class Loading
>>> Requirements
>>>
>>> Components in the application client container must not have access to
>>> the
>>> following classes and resources, *unless such classes or resources are
>>> covered by
>>> one of the rules above.*
>>>
>>> If the ejb jar is in the class-path of app client module,   the module
>>> will have the access to ejb jar.
>>>
>>>
>>>
>>>
>>> On Tue, Jul 12, 2011 at 10:59 PM, Ivan  wrote:
>>>
 Yes, it is by design. App client modules should not have access to web
 modules, ejb modules and other app client modules in the same ear package.


 2011/7/12 viola lu 

> Hi, Dev:
>
>  I met a problem when deploy an ear which packages an ejb, application
> client, web app. And the EJB is in the class-path of app client module
> manifest, but Appclientmodulebuilder class doesn't add this class-path of
> manifest  to module's LinkedHashSet classpath, So it's not in the
> class path of AppclientDeplomentContext either. Is it correct?
> --
> viola
>
> Apache Geronimo
>
>


 --
 Ivan

>>>
>>>
>>>
>>> --
>>> Shawn
>>>
>>
>>
>>
>> --
>> Ivan
>>
>
>
>
> --
> Shawn
>



-- 
Ivan

Re: [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

[Shawn Jiang]

1, "mvn install" build is OK
2, "mvn rat:check" result is clean.

Again, Here is my own +1.

On Tue, Jul 12, 2011 at 11:18 PM, Shawn Jiang  wrote:

> [VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.
>
> This is a bug fix release that only includes one bug fix for GERONIMO-5848
>
> The components up for vote are:
>
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz
>
>
> The staging repository is:
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-019/
>
> The source repo is:
>
>
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/
>
>  Vote will be open for 72 hours.
>
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
>
> --
> Shawn
>



-- 
Shawn

Re: Class-Path in manifest file of applicationclient module.

[Shawn Jiang]

Components in the application client container must have access to the
following
classes and resources.
• The content of the application client jar file.
• The transitive closure of any libraries referenced by the above jar file
(as spec-
ified in Section EE.8.2, “Library Support”).



On Tue, Jul 12, 2011 at 11:10 PM, Ivan  wrote:

> Hmm, I double checked the spec, so which rule should cover this request ?
>
> --->
> • The Java EE API classes specified in Table EE.6-1 for the containers
> other than
> the application client container.
> • Any installed libraries available in the application server.
> • Other classes or resources contained in the application package, and
> specified
> by an explicit use of an extension not defined by this specification.
> • Other classes and resources that are part of the implementation of the
> applica-
> tion server.
> <---
>
>
> 2011/7/12 Shawn Jiang 
>
>> per java ee 6 spec:   EE.8.3.3 Application Client Container Class Loading
>> Requirements
>>
>> Components in the application client container must not have access to the
>>
>> following classes and resources, *unless such classes or resources are
>> covered by
>> one of the rules above.*
>>
>> If the ejb jar is in the class-path of app client module,   the module
>> will have the access to ejb jar.
>>
>>
>>
>>
>> On Tue, Jul 12, 2011 at 10:59 PM, Ivan  wrote:
>>
>>> Yes, it is by design. App client modules should not have access to web
>>> modules, ejb modules and other app client modules in the same ear package.
>>>
>>>
>>> 2011/7/12 viola lu 
>>>
 Hi, Dev:

  I met a problem when deploy an ear which packages an ejb, application
 client, web app. And the EJB is in the class-path of app client module
 manifest, but Appclientmodulebuilder class doesn't add this class-path of
 manifest  to module's LinkedHashSet classpath, So it's not in the
 class path of AppclientDeplomentContext either. Is it correct?
 --
 viola

 Apache Geronimo


>>>
>>>
>>> --
>>> Ivan
>>>
>>
>>
>>
>> --
>> Shawn
>>
>
>
>
> --
> Ivan
>



-- 
Shawn

[VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

[Shawn Jiang]

[VOTE] release StAX 1.2 spec version 1.1 - 2nd attempt.

This is a bug fix release that only includes one bug fix for GERONIMO-5848

The components up for vote are:

https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
https://repository.apache.org/content/repositories/orgapachegeronimo-019/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz


The staging repository is:

https://repository.apache.org/content/repositories/orgapachegeronimo-019/

The source repo is:

https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/

 Vote will be open for 72 hours.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

-- 
Shawn

Re: Is it time to release YOKO 1.2 for G 3.0?

[Kevan Miller]

On Jul 12, 2011, at 12:31 AM, Forrest Xia wrote:

> Hi All,
> 
> I think we come to a point to determine whether to release YOKO 1.2 for G 3.0 
> release. 
> 
> Since rest of YOKO related tck failures are due to RI' problem we think, I 
> would think we could release YOKO 1.2 now.
> 
> If any objection, please speak out, otherwise, I start a vote for that soon.

Yesterday, I probably would have said we shouldn't release Yoko, yet. But 
today, is a different day... ;-) Looks like our test issues have been resolved. 
So, I think we can release Yoko...

--kevan

Re: Class-Path in manifest file of applicationclient module.

[Ivan]

Hmm, I double checked the spec, so which rule should cover this request ?

--->
• The Java EE API classes specified in Table EE.6-1 for the containers other
than
the application client container.
• Any installed libraries available in the application server.
• Other classes or resources contained in the application package, and
specified
by an explicit use of an extension not defined by this specification.
• Other classes and resources that are part of the implementation of the
applica-
tion server.
<---


2011/7/12 Shawn Jiang 

> per java ee 6 spec:   EE.8.3.3 Application Client Container Class Loading
> Requirements
>
> Components in the application client container must not have access to the
> following classes and resources, *unless such classes or resources are
> covered by
> one of the rules above.*
>
> If the ejb jar is in the class-path of app client module,   the module will
> have the access to ejb jar.
>
>
>
>
> On Tue, Jul 12, 2011 at 10:59 PM, Ivan  wrote:
>
>> Yes, it is by design. App client modules should not have access to web
>> modules, ejb modules and other app client modules in the same ear package.
>>
>>
>> 2011/7/12 viola lu 
>>
>>> Hi, Dev:
>>>
>>>  I met a problem when deploy an ear which packages an ejb, application
>>> client, web app. And the EJB is in the class-path of app client module
>>> manifest, but Appclientmodulebuilder class doesn't add this class-path of
>>> manifest  to module's LinkedHashSet classpath, So it's not in the
>>> class path of AppclientDeplomentContext either. Is it correct?
>>> --
>>> viola
>>>
>>> Apache Geronimo
>>>
>>>
>>
>>
>> --
>> Ivan
>>
>
>
>
> --
> Shawn
>



-- 
Ivan

Re: Class-Path in manifest file of applicationclient module.

[Shawn Jiang]

per java ee 6 spec:   EE.8.3.3 Application Client Container Class Loading
Requirements

Components in the application client container must not have access to the
following classes and resources, *unless such classes or resources are
covered by
one of the rules above.*

If the ejb jar is in the class-path of app client module,   the module will
have the access to ejb jar.



On Tue, Jul 12, 2011 at 10:59 PM, Ivan  wrote:

> Yes, it is by design. App client modules should not have access to web
> modules, ejb modules and other app client modules in the same ear package.
>
>
> 2011/7/12 viola lu 
>
>> Hi, Dev:
>>
>>  I met a problem when deploy an ear which packages an ejb, application
>> client, web app. And the EJB is in the class-path of app client module
>> manifest, but Appclientmodulebuilder class doesn't add this class-path of
>> manifest  to module's LinkedHashSet classpath, So it's not in the
>> class path of AppclientDeplomentContext either. Is it correct?
>> --
>> viola
>>
>> Apache Geronimo
>>
>>
>
>
> --
> Ivan
>



-- 
Shawn

Re: Class-Path in manifest file of applicationclient module.

[Ivan]

Yes, it is by design. App client modules should not have access to web
modules, ejb modules and other app client modules in the same ear package.

2011/7/12 viola lu 

> Hi, Dev:
>
>  I met a problem when deploy an ear which packages an ejb, application
> client, web app. And the EJB is in the class-path of app client module
> manifest, but Appclientmodulebuilder class doesn't add this class-path of
> manifest  to module's LinkedHashSet classpath, So it's not in the
> class path of AppclientDeplomentContext either. Is it correct?
> --
> viola
>
> Apache Geronimo
>
>


-- 
Ivan

Class-Path in manifest file of applicationclient module.

[viola lu]

Hi, Dev:

 I met a problem when deploy an ear which packages an ejb, application
client, web app. And the EJB is in the class-path of app client module
manifest, but Appclientmodulebuilder class doesn't add this class-path of
manifest  to module's LinkedHashSet classpath, So it's not in the
class path of AppclientDeplomentContext either. Is it correct?
-- 
viola

Apache Geronimo

Re: [VOTE] release StAX 1.2 spec version 1.1

[Shawn Jiang]

cancelled.  Will clean up the staging and then init the vote again.

On Tue, Jul 12, 2011 at 9:48 PM, Shawn Jiang  wrote:

> [VOTE] release StAX 1.2 spec version 1.1
>
> This is a bug fix release that only includes one fix for GERONIMO-5848
>
> The components up for vote are:
>
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz
>
>
> The maven staging repository is :
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/
>
> The source repo is:
>
>
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/
>
>  Vote will be open for 72 hours.
>
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
>
> --
> Shawn
>



-- 
Shawn

Re: [VOTE] release StAX 1.2 spec version 1.1 cancelled.

[Shawn Jiang]

Canceling this vote since the staging repo contains other bundle that I
don't want to release now.

On Tue, Jul 12, 2011 at 9:48 PM, Shawn Jiang  wrote:

> [VOTE] release StAX 1.2 spec version 1.1
>
> This is a bug fix release that only includes one fix for GERONIMO-5848
>
> The components up for vote are:
>
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz
>
>
> The maven staging repository is :
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/
>
> The source repo is:
>
>
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/
>
>  Vote will be open for 72 hours.
>
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
>
> --
> Shawn
>



-- 
Shawn

Re: [VOTE] release StAX 1.2 spec version 1.1

[Shawn Jiang]

1, "mvn install" build is OK
2, "mvn rat:check" result is clean.

Here is my own +1.

On Tue, Jul 12, 2011 at 9:48 PM, Shawn Jiang  wrote:

> [VOTE] release StAX 1.2 spec version 1.1
>
> This is a bug fix release that only includes one fix for GERONIMO-5848
>
> The components up for vote are:
>
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz
>
>
> The maven staging repository is :
>
> https://repository.apache.org/content/repositories/orgapachegeronimo-014/
>
> The source repo is:
>
>
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/
>
>  Vote will be open for 72 hours.
>
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
>
> --
> Shawn
>



-- 
Shawn

[VOTE] release StAX 1.2 spec version 1.1

[Shawn Jiang]

[VOTE] release StAX 1.2 spec version 1.1

This is a bug fix release that only includes one fix for GERONIMO-5848

The components up for vote are:

https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.zip
https://repository.apache.org/content/repositories/orgapachegeronimo-014/org/apache/geronimo/specs/geronimo-stax-api_1.2_spec/1.1/geronimo-stax-api_1.2_spec-1.1-source-release.tar.gz


The maven staging repository is :

https://repository.apache.org/content/repositories/orgapachegeronimo-014/

The source repo is:

https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-stax-api_1.2_spec-1.1/

 Vote will be open for 72 hours.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

-- 
Shawn

Re: Release geronimo-el and geronimo-jaxws spec package

[Shawn Jiang]

I'm going to release geronimo-stax-api_1.2_spec because jaxb bundle and
woodstox bundle release also depend on this spec.

>
On Thu, Jun 30, 2011 at 3:38 PM, Ivan  wrote:

> Another dependent package is also required to release
> first, geronimo-stax-api_1.2_spec
>
>
> 2011/6/28 Ivan 
>
>> Hi, we just got some fixes for geronimo-el and geronimo-jaxws-2.2 spec
>> package in the past, I am thinking to do those two package release soon if
>> no objection.
>>
>> --
>> Ivan
>>
>
>
>
> --
> Ivan
>



-- 
Shawn

[jira] [Assigned] (GERONIMO-6063) Yoko 1.2-SNAPSHOT

[Forrest Xia (JIRA)]

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

Forrest Xia reassigned GERONIMO-6063:
-

Assignee: Forrest Xia

> Yoko 1.2-SNAPSHOT
> -
>
> Key: GERONIMO-6063
> URL: https://issues.apache.org/jira/browse/GERONIMO-6063
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>Reporter: David Blevins
>Assignee: Forrest Xia
> Fix For: 3.0-M2
>
>


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

Re: buildbot failure in ASF Buildbot on geronimo-server-trunk

[Kevan Miller]

On Jul 12, 2011, at 1:23 AM, David Jencks wrote:

> The build works for me anyone else seeing problems?
> 

Builds fine for me, also.

--kevan

Fwd: EntityManager not closed when a stateful is destroyed

[Jean-Louis MONTEIRO]

FYI

If something fails in Geronimo, please lemme know.

Jean-Louis

-- Forwarded message --
From: Jean-Louis MONTEIRO 
Date: 2011/7/12
Subject: Re: EntityManager not closed when a stateful is destroyed
To: d...@openejb.apache.org


OK, reverted changes yesterday because of an issue with Inherited
Persistence
Context.
Just committed another version with some more tests.
Everything works on my laptop and on the CI.

Jean-Louis



--
View this message in context:
http://openejb.979440.n4.nabble.com/EntityManager-not-closed-when-a-stateful-is-destroyed-tp3658876p3662008.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.

[BUILD] branches/2.2: Failed for Revision: 1145394

[Jarek Gawor]

Geronimo Revision: 1145394 built with tests included
 
See the full build-2000.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110712/build-2000.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110712
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 430 minutes 4 seconds
[INFO] Finished at: Tue Jul 12 03:12:42 EDT 2011
[INFO] Final Memory: 316M/746M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110712/logs-2000-tomcat/
 
[INFO] Running TestSuite
[INFO] Tests run: 40, Failures: 26, Errors: 0, Skipped: 0, Time elapsed: 
215.628 sec <<< FAILURE!
[INFO] Running TestSuite
[INFO] Tests run: 12, Failures: 9, Errors: 0, Skipped: 0, Time elapsed: 59.62 
sec <<< FAILURE!
 
[INFO] [INFO] Copying 3 resources
[INFO] [INFO] [compiler:testCompile {execution: default}]
[INFO] [INFO] Compiling 1 source file to 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/test-classes
[INFO] [INFO] [ear:ear {execution: default-ear}]
[INFO] [INFO] Copying 
artifact[war:org.apache.geronimo.testsuite:jca-cms-war:2.2.2-SNAPSHOT] 
to[web.war]
[INFO] [INFO] Copying 
artifact[rar:org.tranql:tranql-connector-derby-embed-xa:1.7] to[tranql.rar]
[INFO] [INFO] Copy ear resources to 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/jca-cms-ear-2.2.2-SNAPSHOT
[INFO] [INFO] Could not find manifest file: 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/src/main/application/META-INF/MANIFEST.MF
 - Generating one
[INFO] [INFO] Building jar: 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/jca-cms-ear-2.2.2-SNAPSHOT.ear
[INFO] [INFO] [selenium:start-server {execution: start}]
[INFO] Launching Selenium Server
[INFO] Waiting for Selenium Server...
[INFO] [INFO] Including display properties from: 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/selenium/display.properties
[INFO] [INFO] Redirecting output to: 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/selenium/server.log
[INFO] [INFO] User extensions: 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/selenium/user-extensions.js
[INFO] Selenium Server started
[INFO] [INFO] [geronimo:deploy-module {execution: deploy-ears}]
[INFO] [INFO] Using non-artifact based module archive: 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/jca-cms-ear-2.2.2-SNAPSHOT.ear
[INFO] [INFO] Distributing module artifact: 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/jca-cms-ear-2.2.2-SNAPSHOT.ear
[INFO] [INFO] Starting modules...
[INFO] [INFO] Starting module: 
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] Started module(s):
[INFO] [INFO] [0] 
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] [failsafe:integration-test {execution: integration-test}]
[INFO] [INFO] Failsafe report directory: 
/home/geronimo/geronimo/2.2/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/target/failsafe-reports
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running TestSuite
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.9 sec
[INFO] 
[INFO] Results :
[INFO] 
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] [WARNING] File encoding has not been set, using platform encoding 
ANSI_X3.4-1968, i.e. build is platform dependent!
[INFO] [INFO] [selenium:stop-server {execution: stop}]
[INFO] Stopping Selenium server...
[INFO] Stop request sent
[INFO] [INFO] [geronimo:undeploy-module {execution: undeploy-ear-as-module}]
[INFO] [INFO] Using non-artifact based module id: 
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] Stopping module: 
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] Stopped module(s):
[INFO] [INFO] [0] 
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] [0] web.war; URL: /jca-cms
[INFO] [INFO] [1] tranql.rar
[INFO] [INFO] Undeploying module: 
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] Undeployed module(s):
[INFO] [INFO] [0] 
org.apache.geronimo.testsuite/jca-cms-ear/2.2.2-SNAPSHOT/ear
[INFO] [INFO] [failsafe:verify {execution: verify}]
[INFO] [INFO] Failsafe report directory: 
/home/ger

[jira] [Commented] (GERONIMO-5904) Reference bound in JNDI is not dereferenced properly when lookup

[Ivan (JIRA)]

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

Ivan commented on GERONIMO-5904:


Commit the patch to trunk at rev.1145482. Thanks, Fang Sheng Hao !

> Reference bound in JNDI is not dereferenced properly when lookup
> 
>
> Key: GERONIMO-5904
> URL: https://issues.apache.org/jira/browse/GERONIMO-5904
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: naming
>Affects Versions: 3.0
>Reporter: Shenghao Fang
>Assignee: Ivan
> Attachments: GERONIMO-5904.patch
>
>
> Get java.lang.ClassCastException: 
> org.tranql.connector.jdbc.TranqlDataSource$SelfReference cannot be cast to 
> javax.sql.DataSource on the following code snippet.
> {code}
> InitialContext ic = new InitialContext();
> activeDS = 
> (DataSource)ic.lookup("jca:/org.apache.geronimo.plugins.monitoring/agent-ds/JCAConnectionManager/jdbc/ActiveDS");
> {code}
> An instance of org.tranql.connector.jdbc.TranqlDataSource is expected to be 
> returned, but get an instance of 
> org.tranql.connector.jdbc.TranqlDataSource$SelfReference.
> TranqlDataSource implements javax.naming.Referenceable, so an instance of 
> javax.naming.Reference is bound on to JNDI, but it is expected to be 
> dereferenced when lookup.
>  

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

[jira] [Commented] (GERONIMO-5904) Reference bound in JNDI is not dereferenced properly when lookup

[Ivan (JIRA)]

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

Ivan commented on GERONIMO-5904:


Hi, David, here is some background info for this issue. Geronimo maintains a 
jndi tree of namepsace ger, and a listener for gbeans implement ResourceSource 
is added. So, once a gbean of this type is started, its value from invoking 
$getResource() is bind on the tree. With this tree, users could bind some other 
instances on the jndi tree, and use the jndi lookup to get value from their 
applications. I know that we have a URLResourceSource sample, which could be 
used to bind a URL on the tree.
Move to this jira, once a data source is created, a 
GenericConnectionManagerGBean is created, and the return value of 
$getResource() will be bind on the jndi tree. The problems is that the return 
value is a tranql datasource instance, it implements the Referenceable 
interface, so while binding it on our jndi tree, its reference value will be 
used as the real value on the tree. The question is, while looking up this 
value from the tree, no ObjectFactory could be found by aries jndi 
implementation, then bang !
The workaround solution for this is that, a ResourceReference instance is used 
to bind on the jndi tree, not the actual instance. With this, the lookup 
function could work as usual.
Is it clear for you ? I would go ahead to commit this patch, as some other 
JIRAs are depending on this. we could turn to other better solutions if 
possible.

> Reference bound in JNDI is not dereferenced properly when lookup
> 
>
> Key: GERONIMO-5904
> URL: https://issues.apache.org/jira/browse/GERONIMO-5904
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: naming
>Affects Versions: 3.0
>Reporter: Shenghao Fang
>Assignee: Ivan
> Attachments: GERONIMO-5904.patch
>
>
> Get java.lang.ClassCastException: 
> org.tranql.connector.jdbc.TranqlDataSource$SelfReference cannot be cast to 
> javax.sql.DataSource on the following code snippet.
> {code}
> InitialContext ic = new InitialContext();
> activeDS = 
> (DataSource)ic.lookup("jca:/org.apache.geronimo.plugins.monitoring/agent-ds/JCAConnectionManager/jdbc/ActiveDS");
> {code}
> An instance of org.tranql.connector.jdbc.TranqlDataSource is expected to be 
> returned, but get an instance of 
> org.tranql.connector.jdbc.TranqlDataSource$SelfReference.
> TranqlDataSource implements javax.naming.Referenceable, so an instance of 
> javax.naming.Reference is bound on to JNDI, but it is expected to be 
> dereferenced when lookup.
>  

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

[jira] [Assigned] (GERONIMO-5904) Reference bound in JNDI is not dereferenced properly when lookup

[Ivan (JIRA)]

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

Ivan reassigned GERONIMO-5904:
--

Assignee: Ivan  (was: Shenghao Fang)

> Reference bound in JNDI is not dereferenced properly when lookup
> 
>
> Key: GERONIMO-5904
> URL: https://issues.apache.org/jira/browse/GERONIMO-5904
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: naming
>Affects Versions: 3.0
>Reporter: Shenghao Fang
>Assignee: Ivan
> Attachments: GERONIMO-5904.patch
>
>
> Get java.lang.ClassCastException: 
> org.tranql.connector.jdbc.TranqlDataSource$SelfReference cannot be cast to 
> javax.sql.DataSource on the following code snippet.
> {code}
> InitialContext ic = new InitialContext();
> activeDS = 
> (DataSource)ic.lookup("jca:/org.apache.geronimo.plugins.monitoring/agent-ds/JCAConnectionManager/jdbc/ActiveDS");
> {code}
> An instance of org.tranql.connector.jdbc.TranqlDataSource is expected to be 
> returned, but get an instance of 
> org.tranql.connector.jdbc.TranqlDataSource$SelfReference.
> TranqlDataSource implements javax.naming.Referenceable, so an instance of 
> javax.naming.Reference is bound on to JNDI, but it is expected to be 
> dereferenced when lookup.
>  

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

Re: [jira] [Commented] (GERONIMODEVTOOLS-759) Using the new APIs to manage the bundles status both in GEP and Server side

[Yi Xiao]

I've reviewed the code, it's better and more concise than I did[?], thank you
very much, Jarek.

When I test the new feature, I find a problem that when restart the eclipse
and modify the bundle's symbolic name or version, then publish the bundle to
the server, the server would not remove the previous one!

The root cause is when the eclipse restarts, the bundle Map's info is empty,
so it could not get the cached bundle id and also the bundle's symbolic name
or version has been changed, so it could not find the bundle id from server
side by them, the bundle will be an isolated and never used one in server
side.

Maybe we still need persist the bundle map in GEP side, but just persist the
bundle module id, symbolic name,version and the module's state(is removed or
something else), the module state can be obtained by a resource changed
listener as I patched before.
What's your option?

On Tue, Jul 12, 2011 at 1:45 AM, Jarek Gawor (JIRA)  wrote:

>
>[
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063449#comment-13063449]
>
> Jarek Gawor commented on GERONIMODEVTOOLS-759:
> --
>
> In revision 1145251 I refactored the module handling code. I separated it
> into two separate classes - one for handling the Java EE modules and EBAs
> and second one for handling OSGi bundles. I also simplified the OSGi
> handling code.
> Please review in case I missed something.
>
>
> > Using the new APIs to manage  the bundles status both in GEP and Server
> side
> >
> 
> >
> > Key: GERONIMODEVTOOLS-759
> > URL:
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-759
> > Project: Geronimo-Devtools
> >  Issue Type: Improvement
> >  Components: eclipse-plugin
> >Affects Versions: 3.0
> > Environment: WinXP sp3 32bit& Win7 64bit, Oracle JDK 1.6,
> Eclipse3.6SR1&SR2
> >Reporter: Yi Xiao
> >Assignee: Jarek Gawor
> >  Labels: OSGI, bundle
> > Fix For: 3.0
> >
> > Attachments: OSGIBundleDeploy.patch,
> OSGIBundleDeploy_changeAPI.patch, OSGIBundleDeploy_changeAPI2_759.patch,
> OSGIBundleDeploy_changePOM_759.patch
> >
> >
> > This improvement depends on the server's modules, so, if the server side
> does not update timely, it may cause the GEP compile failure!
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>


-- 
Best regards!


   John Xiao
<<330.gif>>

Re: buildbot failure in ASF Buildbot on geronimo-server-trunk

[Rex Wang]

failed for me.

add
 
org.apache.xbean
xbean-bundleutils


can resolve this.

2011/7/12 David Jencks 

> The build works for me anyone else seeing problems?
>
> thanks
> david jencks
>
> On Jul 11, 2011, at 8:25 PM, build...@apache.org wrote:
>
> > The Buildbot has detected a new failure on builder geronimo-server-trunk
> while building ASF Buildbot.
> > Full details are available at:
> > http://ci.apache.org/builders/geronimo-server-trunk/builds/179
> >
> > Buildbot URL: http://ci.apache.org/
> >
> > Buildslave for this Build: hemera_ubuntu
> >
> > Build Reason: scheduler
> > Build Source Stamp: [branch geronimo/server/trunk] 1145439
> > Blamelist: djencks,rwonly
> >
> > BUILD FAILED: failed compile
> >
> > sincerely,
> > -The Buildbot
> >
>
>


-- 
Lei Wang (Rex)
rwonly AT apache.org