date:20080417


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

David Jencks commented on GERONIMO-3964:


Reorganization done in rev 649325

> Concentrate spec security setup for webapps into one class. Consider not 
> using excluded permissions
> ---
>
> Key: GERONIMO-3964
> URL: https://issues.apache.org/jira/browse/GERONIMO-3964
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
>
> The security building code is a bit spread out between the jetty/tomcat web 
> module builders, the parent AbstractWebModuleBuilder, and some classes in 
> geronimo-security.
> (1) reorganize this so its easier to understand with all the code in a single 
> package in the abstract web module builder module.  Also, only use one call 
> to do all the building.
> (2) Theoretically, excluded permissions are a bit weird why not simple 
> not hand out those permissions in the first place?  After the reorganization 
> I'm planning to investigate how plausible this is.  No excluded permissions 
> fit better into a standard rbac framework and are much easier to think about 
> IMO.

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

[jira] Commented: (GERONIMO-3965) Custom LoginModule uses wrong classloader


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

David Jencks commented on GERONIMO-3965:


Contrary to the comments on the mailing list thread, this isn't an openejb 
problem.  Login modules are global resources and we need to set a thread 
context classloader suitable for a realm before trying to use it.  Kinda 
messy but we didn't write the jaas spec.  Openejb doesn't know which app 
you might be interested in at the point it is trying to authenticate you here, 
so it wouldn't know what to do anyway.

I'd like to know what problems you found with the configuration suggestion I 
made in the thread.  The user list would be a good place to discuss that.

> Custom LoginModule uses wrong classloader
> -
>
> Key: GERONIMO-3965
> URL: https://issues.apache.org/jira/browse/GERONIMO-3965
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0.2, 2.1
> Environment: Windows XP, JDK 1.5
>Reporter: Kory Markevich
>Assignee: David Jencks
>
> When specifying a custom LoginModule implementation in a 
> geronimo-application.xml file, the class cannot be loaded if it is in the 
> EAR.  Debugging, the classloader being used belongs to OpenEJB rather than 
> the one for the application.  I have tried both versions 2.0.2 and 2.1.
> This bug was discovered and discussed in the mailing lists 
> (http://www.nabble.com/Custom-LoginModule-classloading-issue-in-gernimo-2.0.2-td14404472s134.html)
>  but I couldn't find any JIRA's for it.  Note that the workaround discussed 
> in the thread cannot be used in our application, though I tried it anyway and 
> couldn't get it working.

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

[jira] Assigned: (GERONIMO-3965) Custom LoginModule uses wrong classloader


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

David Jencks reassigned GERONIMO-3965:
--

Assignee: David Jencks

> Custom LoginModule uses wrong classloader
> -
>
> Key: GERONIMO-3965
> URL: https://issues.apache.org/jira/browse/GERONIMO-3965
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0.2, 2.1
> Environment: Windows XP, JDK 1.5
>Reporter: Kory Markevich
>Assignee: David Jencks
>
> When specifying a custom LoginModule implementation in a 
> geronimo-application.xml file, the class cannot be loaded if it is in the 
> EAR.  Debugging, the classloader being used belongs to OpenEJB rather than 
> the one for the application.  I have tried both versions 2.0.2 and 2.1.
> This bug was discovered and discussed in the mailing lists 
> (http://www.nabble.com/Custom-LoginModule-classloading-issue-in-gernimo-2.0.2-td14404472s134.html)
>  but I couldn't find any JIRA's for it.  Note that the workaround discussed 
> in the thread cannot be used in our application, though I tried it anyway and 
> couldn't get it working.

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

[jira] Created: (GERONIMO-3965) Custom LoginModule uses wrong classloader

2008-04-17 Thread Kory Markevich (JIRA)

Custom LoginModule uses wrong classloader
-

 Key: GERONIMO-3965
 URL: https://issues.apache.org/jira/browse/GERONIMO-3965
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.1, 2.0.2
 Environment: Windows XP, JDK 1.5
Reporter: Kory Markevich


When specifying a custom LoginModule implementation in a 
geronimo-application.xml file, the class cannot be loaded if it is in the EAR.  
Debugging, the classloader being used belongs to OpenEJB rather than the one 
for the application.  I have tried both versions 2.0.2 and 2.1.

This bug was discovered and discussed in the mailing lists 
(http://www.nabble.com/Custom-LoginModule-classloading-issue-in-gernimo-2.0.2-td14404472s134.html)
 but I couldn't find any JIRA's for it.  Note that the workaround discussed in 
the thread cannot be used in our application, though I tried it anyway and 
couldn't get it working.

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

[jira] Created: (GERONIMO-3964) Concentrate spec security setup for webapps into one class. Consider not using excluded permissions

Concentrate spec security setup for webapps into one class. Consider not using 
excluded permissions
---

 Key: GERONIMO-3964
 URL: https://issues.apache.org/jira/browse/GERONIMO-3964
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.2
Reporter: David Jencks
Assignee: David Jencks
 Fix For: 2.2


The security building code is a bit spread out between the jetty/tomcat web 
module builders, the parent AbstractWebModuleBuilder, and some classes in 
geronimo-security.
(1) reorganize this so its easier to understand with all the code in a single 
package in the abstract web module builder module.  Also, only use one call to 
do all the building.

(2) Theoretically, excluded permissions are a bit weird why not simple not 
hand out those permissions in the first place?  After the reorganization I'm 
planning to investigate how plausible this is.  No excluded permissions fit 
better into a standard rbac framework and are much easier to think about IMO.

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

Re: Geronimo specs jars in OSGi

On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> I must be missing something.  That legacy code would not need to change.
> The whiteboard pattern only obviates the need to scavenge every bundle the
> META-INF/services entries.  The rest works as you say.
>
>  But, as I think about it some more, I'm thinking that this is over
> engineering it.  Let's drop this aspect of the thread.
>

Actually it may be a good idea.  I think it would allow running
multiple versions concurrently.
This would be true for jaxb 2.0 / 2.1 I think.  The reason is that the
way I've done that, if you
deploy a jaxb 2.1 spec jar, it could try to create a jaxb 2.0
implementation.  However, using the
whiteboard pattern, the implementation bundle would register its own
factory in OSGi, while the
spec jar would listen for compatible services.  The benefit is that
OSGi can check the service
implementation wrt to classloader constraints and would not allow the
jaxb 2.1 spec bundle to
see a service implementing jaxb 2.0.   This would only work if we use
the versions on the packages,
but it may be worth the extra work.

-- 
Cheers,
Guillaume Nodet

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

[jira] Created: (GERONIMO-3963) Remote deployment using the --inPlace option

2008-04-17 Thread Jacques Le Roux (JIRA)

Remote deployment using the --inPlace option


 Key: GERONIMO-3963
 URL: https://issues.apache.org/jira/browse/GERONIMO-3963
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 2.0.x
 Environment: Tested on Windows XP but Linux should be the same except 
the drive constraint
Reporter: Jacques Le Roux
Priority: Minor


Remote deployment using the --inPlace option (for a totally exploded EAR with 
exploded and only exploded WARs inside) is only possible if you exactly 
replicate the deployed directory structure on both the client and the server 
machine. If you are on Windows you must even replicate the drive.

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

[BUILD] branches/2.1: Failed for Revision: 649202

2008-04-17 Thread gawor

Geronimo Revision: 649202 built with tests included
 
See the full build-1400.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417/build-1400.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 35 minutes 27 seconds
[INFO] Finished at: Thu Apr 17 14:44:22 EDT 2008
[INFO] Final Memory: 305M/1013M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417/logs-1400-tomcat/test.log
 
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417/logs-1400-jetty/test.log
 
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 77.03 
sec <<< FAILURE!
 
Samples: branches/2.1
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417/samples-1400.log
 
Build status: OK

[jira] Commented: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar


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

Guillaume Nodet commented on GERONIMO-3962:
---

Agreed, I'll do that.  Actually, i thought axis was using the sun jar too so i 
rewrote that one quickly but it does not pass the tck.
I'll create a patch from the axis2 version.  

And I agree with the duplication, but since there are so many spec jars in 
geronimo already, it makes more sense to move them here imho.










> AL2 and OSGi friendy JAX-WS 2.0 spec jar
> 
>
> Key: GERONIMO-3962
> URL: https://issues.apache.org/jira/browse/GERONIMO-3962
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Attachments: jaxws-2.0.diff
>
>


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

[jira] Closed: (GERONIMO-3900) Add runtime support for non-Sun JVMs


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

Donald Woods closed GERONIMO-3900.
--

Resolution: Fixed

Merged in earlier updates from 2.1.1 into trunk (2.2) via revision 649215.

> Add runtime support for non-Sun JVMs
> 
>
> Key: GERONIMO-3900
> URL: https://issues.apache.org/jira/browse/GERONIMO-3900
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: common
>Affects Versions: 1.x, 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Donald Woods
>Assignee: Donald Woods
> Fix For: 2.1.1, 2.2
>
>
> Add support for non-Sun JVMs.
> The IBM JVM needs a different cert handler setup.
> Will also add initial Harmony support, which will need to be refined once the 
> TCK is running against it.
> Will reuse the SystemProperties GBean, but extend it to support Sun vs. IBM 
> vs. Harmony specific property settings.
> Will also add a JvmVendor class, to properly detect the JVM being used at 
> runtime.

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

[jira] Assigned: (GERONIMO-3961) Upgrade GShell to use the latest Groovy 1.5.x release

2008-04-17 Thread Jason Dillon (JIRA)


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

Jason Dillon reassigned GERONIMO-3961:
--

Assignee: Jason Dillon

> Upgrade GShell to use the latest Groovy 1.5.x release
> -
>
> Key: GERONIMO-3961
> URL: https://issues.apache.org/jira/browse/GERONIMO-3961
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: dependencies
>Affects Versions: 2.1.x, 2.2
>Reporter: Donald Woods
>Assignee: Jason Dillon
> Fix For: 2.1.x, 2.2
>
>
> It seems that we used an old groupId for the groovy-all GShell depend.
> The latest groovy releases (1.1-1.5.5) were published using a new groupId -
>org.codehaus.groovy
> and can be found under -
>http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/
> We should upgrade to a 1.5.x version of groovy, so we are current with their 
> releases.

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

[jira] Commented: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar

2008-04-17 Thread Jarek Gawor (JIRA)


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

Jarek Gawor commented on GERONIMO-3962:
---

I would be happier if I knew that this JAX-WS 2.0 api was scp copy-ied from 
Axis2 1_3 branch first before the OSGi modifications are added in. Can you 
please create the jaxws spec module from Axis2 code base first (although I'm 
still against this duplication between Geronimo and Axis2)?


> AL2 and OSGi friendy JAX-WS 2.0 spec jar
> 
>
> Key: GERONIMO-3962
> URL: https://issues.apache.org/jira/browse/GERONIMO-3962
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Attachments: jaxws-2.0.diff
>
>


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

Re: Geronimo 2.1.1 RELEASE-NOTE & README questions.

2008-04-17 Thread Joe Bohn

Kevan Miller wrote:

Sorry, started typing this yesterday and got distracted...

On Apr 16, 2008, at 5:04 PM, Hernan Cunico wrote:

Joe Bohn wrote:

RELEASE_NOTES:
1) I've noticed that we actually have 2 RELEASE_NOTES-2.1.txt files
in our source. They are both identical. One is in our root ...
branches/2.1.1/RELEASE-NOTES-2.1.txt. The other is
branches/2.1.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/RELEASE_NOTES-2.1.txt.
Are both of these necessary? If not, which one is really required?

The one in branches/2.1.1/ is for source distributions. The copy in
underlay/ is for binary distributions. If you can figure out how to
include the branches/2.1.1/ copy into our binary distributions, then
just that one is sufficient. Otherwise, we should have both...

2) How elaborate do the release notes need to be for a maintenance
release like 2.1.1? For example, our 2.1 release notes included a
list of enhancements explaining each. I was just planning to list
the JIRAs that were included in the release since most items are bug
fixes and remove the 2.1 enhancement content. Is that sufficient and
what we have done in the past?

If it is only bug fixes then that should be the focus, no need to
include the "Geronimo 2.1 Enhancements" again I guess.
We need to make sure we clearly mention this is a maintenance release
and that no new functionality has been introduced

Personally, I'd make the bug fixes cumulative -- 2.1 enhancements +
2.1.1 bug fixes. Next service release we add 2.1.2 bug fixes.

I was originally thinking the same thing ... then I checked back at
2.0.2 and 2.0 to discover that the original enhancements were not
included in subsequent release notes. However, since we were both
thinking the same thing I'll go with my original intent and update the
release notes the wiki to include both.

3) Why is the version number in the name? I assume that I need to
rename the current one to reflect that this is 2.1.1 ... but it might
be better to just remove the version number completely when I rename it.

For one, it help us develop/maintain the release notes in the wiki
(can't have 2 files with the same name). Second, I guess it's the
fastest way to know the installed version. Specially when you have
multiple installs and have been chopping the directory
to single characters to run "worry free" on certain platform ;-)

Cheers!
Hernan

README.txt:
4) As with the RELEASE_NOTES we also have 2 instances of the
README.txt file in our source. One is in our root ...
branches/2.1.1/README.txt. The other is
branches/2.1.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/README.txt.
There is one minor difference between the 2 files. Are both of these
necessary and if not, which one is required?

Same reason as above...

--kevan

[jira] Updated: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar


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

Guillaume Nodet updated GERONIMO-3962:
--

Attachment: jaxws-2.0.diff

> AL2 and OSGi friendy JAX-WS 2.0 spec jar
> 
>
> Key: GERONIMO-3962
> URL: https://issues.apache.org/jira/browse/GERONIMO-3962
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Attachments: jaxws-2.0.diff
>
>


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

[jira] Created: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar

AL2 and OSGi friendy JAX-WS 2.0 spec jar


 Key: GERONIMO-3962
 URL: https://issues.apache.org/jira/browse/GERONIMO-3962
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: specs
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet




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

[jira] Updated: (GERONIMO-3900) Add runtime support for non-Sun JVMs


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

Donald Woods updated GERONIMO-3900:
---

Fix Version/s: (was: 2.1.x)
   (was: 2.0.x)
   2.1.1

Still need to apply the updates to trunk (2.2.)
Removing 2.0.x as a target fix release.

> Add runtime support for non-Sun JVMs
> 
>
> Key: GERONIMO-3900
> URL: https://issues.apache.org/jira/browse/GERONIMO-3900
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: common
>Affects Versions: 1.x, 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Donald Woods
>Assignee: Donald Woods
> Fix For: 2.1.1, 2.2
>
>
> Add support for non-Sun JVMs.
> The IBM JVM needs a different cert handler setup.
> Will also add initial Harmony support, which will need to be refined once the 
> TCK is running against it.
> Will reuse the SystemProperties GBean, but extend it to support Sun vs. IBM 
> vs. Harmony specific property settings.
> Will also add a JvmVendor class, to properly detect the JVM being used at 
> runtime.

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

[jira] Updated: (GERONIMO-3244) Tasklist for adding new marshalling/unmarshalling testset(s) to the Corba testsuite


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

Donald Woods updated GERONIMO-3244:
---

Affects Version/s: 2.2
   2.1.x
Fix Version/s: (was: 2.0.x)

setting Fix Versions to unknown, until this work starts up again

> Tasklist for adding new marshalling/unmarshalling testset(s) to the Corba 
> testsuite
> ---
>
> Key: GERONIMO-3244
> URL: https://issues.apache.org/jira/browse/GERONIMO-3244
> Project: Geronimo
>  Issue Type: Test
>  Security Level: public(Regular issues) 
>  Components: CORBA
>Affects Versions: 2.0.x, 2.1.x, 2.2
>Reporter: Tim McConnell
>Assignee: Tim McConnell
>


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

[jira] Updated: (GERONIMO-3389) console: java.lang.UnsatisfiedLinkError is thrown when create a Tomcat APR HTTP Connector


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

Donald Woods updated GERONIMO-3389:
---

Affects Version/s: 2.2
   2.1.x
   2.1.1
   2.0.1
   2.0.2
Fix Version/s: (was: 2.0.x)

> console: java.lang.UnsatisfiedLinkError is thrown when create a Tomcat APR 
> HTTP Connector
> -
>
> Key: GERONIMO-3389
> URL: https://issues.apache.org/jira/browse/GERONIMO-3389
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: documentation, Tomcat
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.1.x, 2.2
> Environment: Windows xp sp2, IE, Firefox
>Reporter: Song
>
>   Click on "Save" button after entering all necessary parameters for creating 
> a new Tomcat APR HTTP Connector "test_APR_HTTP", it returned to the Network 
> Listeners list page. However,the Protocol for test_APR_HTTP is empty, State 
> is failed. And java.lang.UnsatisfiedLinkError is thrown from the server 
> started console and server.log.
>   Same error to creating Tomcat APR HTTPS Connetor.
>   
> Detailed error as below:
> --
> 13:33:46,515 WARN  [ConnectorGBean] test_APR_HTTP connector failed
> 13:33:46,515 ERROR [Connector] Coyote connector has not been started
> 13:33:46,515 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car,j2eeType=GBean,name=test_APR_HTTP"
> java.lang.UnsatisfiedLinkError: org/apache/tomcat/jni/Pool.create(J)J
>   at org.apache.tomcat.util.net.AprEndpoint.init(AprEndpoint.java:579)
>   at 
> org.apache.coyote.http11.Http11AprProtocol.init(Http11AprProtocol.java:121)
>   at 
> org.apache.catalina.connector.Connector.initialize(Connector.java:1059)
>   at 
> org.apache.catalina.core.StandardService.addConnector(StandardService.java:267)
>   at org.apache.catalina.startup.Embedded.addConnector(Embedded.java:327)
>   at 
> org.apache.geronimo.tomcat.TomcatContainer.addConnector(TomcatContainer.java:383)
>   at 
> org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke()
>   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>   at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
>   at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>   at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>   at 
> org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$fa3733e1.addConnector()
>   at 
> org.apache.geronimo.tomcat.connector.ConnectorGBean.doStart(ConnectorGBean.java:95)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365)
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>   at 
> org.apache.geronimo.tomcat.connector.Http11APRProtocol$$EnhancerByCGLIB$$abc46ac2.startRecursive()
>   at 
> org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:146)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>   at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>   at 
> org.apache.catalina.core.Appli

[jira] Updated: (GERONIMO-3392) CA Helper App - Unable to find HTTPS Connector configured for ClientAuth


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

Donald Woods updated GERONIMO-3392:
---

Affects Version/s: 2.1.x
   2.1.1
   2.0.1
   2.0.2
   2.1
Fix Version/s: (was: 2.2)
   (was: 2.0.x)

> CA Helper App - Unable to find HTTPS Connector configured for ClientAuth
> 
>
> Key: GERONIMO-3392
> URL: https://issues.apache.org/jira/browse/GERONIMO-3392
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.1.x, 2.2
> Environment: G 2.0 Tomcat
>Reporter: Vamsavardhana Reddy
>
> The CA Helper application is unable to find HTTPS Connector configured for 
> ClientAuth.  This is because the new Tomcat HTTPS Connector GBeans no longer 
> implement TomcatSecureConnector and so 
> AbstractNameQuery(SecureConnector.class.getName()) will not help fetch Tomcat 
> SSL Connectors.

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

[jira] Updated: (GERONIMO-3466) car-maven-plugin can not generate server plugin which includes EJB


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

Donald Woods updated GERONIMO-3466:
---

Affects Version/s: 2.2
   2.1.x
   2.1.1
   2.0.x
   2.1
Fix Version/s: (was: 2.0.x)

> car-maven-plugin can not generate server plugin which includes EJB
> --
>
> Key: GERONIMO-3466
> URL: https://issues.apache.org/jira/browse/GERONIMO-3466
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 2.0.1, 2.0.x, 2.1, 2.1.1, 2.1.x, 2.2
>Reporter: YunFeng Ma
>Assignee: David Jencks
> Attachments: calculator-stateless-ear.zip
>
>
> openejb-deployer configuration depends on openejb configuration, and openejb 
> configuration depends on j2ee-server configuration. That means 
> car-maven-plugin has to start all the depended configurations, not only the 
> openejb-deployer configuration. This caused the following error.
> {code}
> [INFO] Scanning for projects...
> [INFO] 
> -
> ---
> [INFO] Building daytrader-derby-tomcat
> [INFO]task-segment: [install]
> [INFO] 
> -
> ---
> [INFO] [dependency:unpack {execution: unpack-distribution}]
> [INFO] Configured Artifact: 
> org.apache.geronimo.daytrader:daytrader-ear:2.0:ear
> [INFO] daytrader-ear-2.0.ear already unpacked.
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [car:prepare-plan]
> [INFO] Generated: 
> F:\WASCE\samples_v2\plugins\daytrader-derby-tomcat\target\plan
> \plan.xml
> log4j:WARN No appenders could be found for logger 
> (org.codehaus.mojo.pluginsuppo
> rt.logging.Logging).
> log4j:WARN Please initialize the log4j system properly.
> [INFO] [car:package]
> [INFO] Packaging module configuration: 
> F:\WASCE\samples_v2\plugins\daytrader-der
> by-tomcat\target\plan\plan.xml
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] start of org.apache.geronimo.configs/openejb-deployer/2.0.1/car failed
> Configuration org.apache.geronimo.configs/j2ee-system/2.0.1/car failed to 
> start
> due to the following reasons:
>   The service 
> ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
> eeType=GBean,name=ServerInfo did not start because Could not determine 
> geronimo
> installation directory
>   The service 
> ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
> eeType=Repository,name=Repository did not start because 
> org.apache.geronimo.conf
> igs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/
> 2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
>   The service 
> ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
> eeType=ConfigurationStore,name=Local did not start because 
> org.apache.geronimo.c
> onfigs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-syst
> em/2.0.1/car,j2eeType=Repository,name=Repository did not start.
>   The service 
> ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
> eeType=AttributeStore,name=AttributeManager did not start because 
> org.apache.ger
> onimo.configs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2
> ee-system/2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
>   The service 
> ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
> eeType=ArtifactResolver,name=ArtifactResolver did not start because 
> org.apache.g
> eronimo.configs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/
> j2ee-system/2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
>   The service 
> ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
> eeType=ConfigurationManager,name=ConfigurationManager did not start because 
> the
> following dependent services did not start: 
> [org.apache.geronimo.configs/j2ee-sy
> stem/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j
> 2eeType=ArtifactResolver,name=ArtifactResolver, 
> org.apache.geronimo.configs/j2ee
> -system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/ca
> r,j2eeType=AttributeStore,name=AttributeManager]
>   The service 
> ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
> eeType=SystemLog,name=Logger did not start because 
> org.apache.geronimo.configs/j
> 2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1
> /car,j2eeType=GBean,name=Se

Re: Geronimo 2.1.1 RELEASE-NOTE & README questions.

2008-04-17 Thread Kevan Miller


Sorry, started typing this yesterday and got distracted...

On Apr 16, 2008, at 5:04 PM, Hernan Cunico wrote:


Joe Bohn wrote:

RELEASE_NOTES:
1) I've noticed that we actually have 2 RELEASE_NOTES-2.1.txt files  
in our source.  They are both identical.   One is in our root ...  
branches/2.1.1/RELEASE-NOTES-2.1.txt.  The other is branches/2.1.1/ 
assemblies/geronimo-boilerplate-minimal/src/main/underlay/ 
RELEASE_NOTES-2.1.txt.  Are both of these necessary?  If not, which  
one is really required?


The one in branches/2.1.1/ is for source distributions. The copy in  
underlay/ is for binary distributions. If you can figure out how to  
include the branches/2.1.1/ copy into our binary distributions, then  
just that one is sufficient. Otherwise, we should have both...




2) How elaborate do the release notes need to be for a maintenance  
release like 2.1.1?  For example, our 2.1 release notes included a  
list of enhancements explaining each.  I was just planning to list  
the JIRAs that were included in the release since most items are  
bug fixes and remove the 2.1 enhancement content.  Is that  
sufficient and what we have done in the past?


If it is only bug fixes then that should be the focus, no need to  
include the "Geronimo 2.1 Enhancements" again I guess.
We need to make sure we clearly mention this is a maintenance  
release and that no new functionality has been introduced


Personally, I'd make the bug fixes cumulative -- 2.1 enhancements +  
2.1.1 bug fixes. Next service release we add 2.1.2 bug fixes.





3) Why is the version number in the name?  I assume that I need to  
rename the current one to reflect that this is 2.1.1 ... but it  
might be better to just remove the version number completely when I  
rename it.


For one, it help us develop/maintain the release notes in the wiki  
(can't have 2 files with the same name). Second, I guess it's the  
fastest way to know the installed version. Specially when you have  
multiple installs and have been chopping the   
directory to single characters to run "worry free" on certain  
platform ;-)


Cheers!
Hernan


README.txt:
4) As with the RELEASE_NOTES we also have 2 instances of the  
README.txt file in our source.  One is in our root  ... branches/ 
2.1.1/README.txt.  The other is branches/2.1.1/assemblies/geronimo- 
boilerplate-minimal/src/main/underlay/README.txt.  There is one  
minor difference between the 2 files.  Are both of these necessary  
and if not, which one is required?


Same reason as above...

--kevan

[jira] Updated: (GERONIMO-3756) Blank screen in Security Realms portlet if wrong file path is specified


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

Donald Woods updated GERONIMO-3756:
---

Fix Version/s: (was: 2.0.x)

> Blank screen in Security Realms portlet if wrong file path is specified
> ---
>
> Key: GERONIMO-3756
> URL: https://issues.apache.org/jira/browse/GERONIMO-3756
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0.2
> Environment: All
>Reporter: Manu T George
>
> When I try to create a property file realm from the security realms portlet 
> and I give a wrong file path for the user and group files, I get a blank 
> screen on clicking next.

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

[jira] Resolved: (GERONIMO-3416) make some -test artifacts that for instance start up a mock server suitable for testing deployment parts


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

Donald Woods resolved GERONIMO-3416.


Resolution: Fixed

This has been inactive for about 8 months since the patch was applied, so 
marking it as resolved.  Please reopen if there is more work required.

> make some -test artifacts that for instance start up a mock server suitable 
> for testing deployment parts
> 
>
> Key: GERONIMO-3416
> URL: https://issues.apache.org/jira/browse/GERONIMO-3416
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.1
>
>
> There's a lot of duplicated code among the deployer tests.  A lot of it could 
> be simplified if we had one or two -test.jar artifacts from appropriate 
> modules (kernel and system come to mind)  that for instance set up a "mock 
> server" with config stores, repos, etc etc started.

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

Re: Geronimo specs jars in OSGi

2008-04-17 Thread Daniel Kulp

On Thursday 17 April 2008, Alan D. Cabrera wrote:
> On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote:
> > I've thought about this.  The main problem is that you end up having
> > two different
> > jars for the spec, one being a plain jar and another one being an
> > OSGi bundle.
> > Both would not be compatible if the bundle embeds the spec jar,
> > because non osgi
> > environment would not be able to load the jar inside the bundle.
> > Imho, creating two different jars would confuse the users and be
> > more error prone.
>
> Non OSGi environments use the vanilla jar as they currently do.  OSGi
> environments load the spec bundle.  Doesn't seem confusing to me.

Well, it IS confusing when you have projects that are required to work in 
both OSGi and non-OSGi environments.   Suddenly, they have to ship two 
versions of the same jar so downloads are bigger.   They have to 
document when they can use one versus the other.  You have to deal with 
users that don't read the docs and try to do something with the wrong 
one, etc...   Not fun.

There are also issues with maven and dependencies (must depend on the 
non-osgi for compiling, but the non-osgi for testing/shipping?), but 
that's a completely different issue.  


Dan



>
> > On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera
> >
> > <[EMAIL PROTECTED]> wrote:
> >> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
> >>> In the past months, I've been working on making the specs jars
> >>> from
> >>
> >> Geronimo working in an OSGi environment.
> >>
> >>> All these jars have been published and work great :-)
> >>> However, lots of these spec jars define factories (stax, saaj for
> >>> example)
> >>
> >> that use the META-INF/services/ discovery mechanism to find an
> >> implementation of the spec and load it.  This mechanism does not
> >> fit well in
> >> OSGi (really, it does not), mainly because usually, the classloader
> >> containing the spec jar will not contain the implementation.
> >>
> >>> I'd like to work on these spec jars so that they will contain an
> >>> OSGi
> >>
> >> BundleActivator that would change the behavior of these factories
> >> when
> >> deployed in an OSGi environment (without changing the behavior in
> >> other
> >> case).  The idea is that the activator would scan OSGi bundles when
> >> they are
> >> started to find META-INF/services and populate a map that would be
> >> used by
> >> the factory when creating an object before using the standard
> >> mechanism.
> >>
> >>> The only real difference compared to what we currently have would
> >>> be the
> >>
> >> addition of a package named org.apache.geronimo.specs.stax (for
> >> example)
> >> that would contain the needed classes (i suppose two classes), and
> >> the
> >> modification of the factories to delegate to one of these class
> >> before using
> >> the standard behavior (the class would do nothing if not deployed
> >> in an OSGi
> >> environment).
> >>
> >>> Has anyone any objection with such an enhancement in the specs jar
> >>> ?
> >>
> >> I would prefer to have a virgin spec jar wrapped inside an OSGi
> >> bundle.
> >> Here the virgin factories would be overshadowed by the OSGi
> >> specific factories.
> >>
> >> I feel strongly about this but am willing to discuss it.
> >>
> >>
> >> Regards,
> >> Alan
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > 
> > Blog: http://gnodet.blogspot.com/



-- 
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

[jira] Created: (GERONIMO-3961) Upgrade GShell to use the latest Groovy 1.5.x release

Upgrade GShell to use the latest Groovy 1.5.x release
-

 Key: GERONIMO-3961
 URL: https://issues.apache.org/jira/browse/GERONIMO-3961
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: dependencies
Affects Versions: 2.1.x, 2.2
Reporter: Donald Woods
 Fix For: 2.1.x, 2.2


It seems that we used an old groupId for the groovy-all GShell depend.
The latest groovy releases (1.1-1.5.5) were published using a new groupId -
   org.codehaus.groovy
and can be found under -
   http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/

We should upgrade to a 1.5.x version of groovy, so we are current with their 
releases.


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

[jira] Updated: (GERONIMODEVTOOLS-266) GEP automation testsuite

2008-04-17 Thread B.J. Reed (JIRA)


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

B.J. Reed updated GERONIMODEVTOOLS-266:
---

Attachment: GERONIMODEVTOOLS-259e.patch

GERONIMODEVTOOLS-259e.patch to add the test for all values for building an 
Application Client XML file.

> GEP automation testsuite
> 
>
> Key: GERONIMODEVTOOLS-266
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-266
> Project: Geronimo-Devtools
>  Issue Type: Sub-task
>Reporter: Tim McConnell
>Assignee: Tim McConnell
> Attachments: GERONIMO-259a.patch, GERONIMODEVTOOLS-259b.patch, 
> GERONIMODEVTOOLS-259c.patch, GERONIMODEVTOOLS-259d.patch, 
> GERONIMODEVTOOLS-259e.patch
>
>


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

Re: Geronimo 2.1.1 RELEASE-NOTE & README questions.

2008-04-17 Thread Joe Bohn

I've created an initial version of the Release Notes in the wiki at this 
location:  http://cwiki.apache.org/GMOxDOC21/release-notes-211txt.html


If there are no issues I will go ahead and include this exact same 
content in a RELEASE-NOTES-2.1.1.TXT for the 2.1.1 branch.


Any opinion on which of the 2 locations I mentioned earlier is the 
correct location for the RELEASE-NOTES?  If I don't hear anything I'll 
just include it in both places as we did for 2.1.   Ditto for the 
README.TXT and it's 2 locations (after I get them both in sync).


Joe

Re: Geronimo specs jars in OSGi

On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> I must be missing something.  That legacy code would not need to change.
> The whiteboard pattern only obviates the need to scavenge every bundle the
> META-INF/services entries.  The rest works as you say.

You mean, having each implementation jar register a service in the
osgi registry ?
Yeah, doable.  Just requires more work.

>
>  But, as I think about it some more, I'm thinking that this is over
> engineering it.  Let's drop this aspect of the thread.
>
>  I still feel strongly that the virgin spec jar should be wrapped in a
> bundle.

I can understand that there is legal  problems changing the behavior
of the spec, but I'm not sure how repackaging it would lead to a different
conclusion: the behavior would still be changed.

If we do use a separate bundle,  I would lean towards removing the existing
manifest headers so that there is no confusion, but I don't really see
the benefit
of doing this.  The added code would not run in a non-osgi environment, so
there is not much risk there.

>
>
>  Regards,
>  Alan
>
>
>  On Apr 17, 2008, at 7:54 AM, Guillaume Nodet wrote:
>
>
> > i don't mean legacy jars but legacy *code*.
> > If you have a jar which uses
> >  javax.xml.stream.XMLInputFactory.newInstance()
> > somewhere deep in the code, I don't really understand how using a
> whiteboard
> > pattern will solve the problem.  I'm not trying to make people rewrite
> > everything,
> > but rather make things easy for them to deploy their application and keep
> the
> > behavior they are used to see.
> > it could be you want to deploy the jaxws-ri, jersey or any other xml
> related
> > technology that could use SAAJ, Stax, Jaxb2 ...
> >
> >
> > On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera <[EMAIL PROTECTED]>
> wrote:
> >
> > > IIUC, they're not entirely legacy, i.e. you at least put in the OSGi
> > > manifest entries.  You do so using the maven/BND plugin I suspect.
> > >
> > >  This strikes me as a common service discovery pattern.  Off the top of
> my
> > > head I would think that a plugin that adds the necessary BundleActivator
> for
> > > legacy modules would be useful.
> > >
> > >  Another thought that flashed in my head is that in a buttoned down
> > > environment getting service notifications might be easier than getting
> > > access to every Bundle's class loader.
> > >
> > >
> > >  Regards,
> > >  Alan
> > >
> > >
> > >
> > >  On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:
> > >
> > >
> > >
> > > > Cleaner, but the main problem is that it does not work with legacy
> code.
> > > > Will you rewrite the jaxb2 implementation to do that instead of using
> the
> > > >
> > > stax
> > >
> > > > factory ? ;-)
> > > > We've got tons of legacy stuff that use stax, or jaxb2 and i don't see
> > > >
> > > rewriting
> > >
> > > > the whole lot as realistic.  it would also mean having an OSGi
> specific
> > > >
> > > thing
> > >
> > > > everywhere we use a factory from a j2ee spec :-(
> > > >
> > > > On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera
> <[EMAIL PROTECTED]>
> > > >
> > > wrote:
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski
> > > > > >
> > > > >
> > > >
> > > <[EMAIL PROTECTED]>
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet
> <[EMAIL PROTECTED]>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > However, lots of these spec jars define factories (stax, saaj
> for
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > example)
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > that use the META-INF/services/ discovery mechanism to find an
> > > > > > > > implementation of the spec and load it.  This mechanism does
> not
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > fit
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > well in
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > OSGi (really, it does not), mainly because usually, the
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > classloader
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > > containing the spec jar will not contain the implementation.
> > > > > > > > I'd like to work on these spec jars so that they will contain
> an
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > OSGi
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > > BundleActivator that would c

[jira] Commented: (GERONIMO-3960) Make the spec jars OSGi friendly


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

Guillaume Nodet commented on GERONIMO-3960:
---

Yeah, not sure what events are exactly sent, but looking at the figure 4.26 
(section 4.3.2 of the osgi r4 core spec), it seems like a bundle that is 
resolved will go back to the install stated after an update or a refresh, then 
back to the resolved state.  If this is true, then the code should handle it 
correctly.
I guess this would need to be property checked though.

> Make the spec jars OSGi friendly
> 
>
> Key: GERONIMO-3960
> URL: https://issues.apache.org/jira/browse/GERONIMO-3960
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Guillaume Nodet
> Attachments: stax-osgi.diff
>
>


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

Re: Geronimo specs jars in OSGi

I must be missing something.  That legacy code would not need to  
change.  The whiteboard pattern only obviates the need to scavenge  
every bundle the META-INF/services entries.  The rest works as you say.


But, as I think about it some more, I'm thinking that this is over  
engineering it.  Let's drop this aspect of the thread.


I still feel strongly that the virgin spec jar should be wrapped in a  
bundle.



Regards,
Alan

On Apr 17, 2008, at 7:54 AM, Guillaume Nodet wrote:


i don't mean legacy jars but legacy *code*.
If you have a jar which uses
  javax.xml.stream.XMLInputFactory.newInstance()
somewhere deep in the code, I don't really understand how using a  
whiteboard

pattern will solve the problem.  I'm not trying to make people rewrite
everything,
but rather make things easy for them to deploy their application  
and keep the

behavior they are used to see.
it could be you want to deploy the jaxws-ri, jersey or any other  
xml related

technology that could use SAAJ, Stax, Jaxb2 ...


On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]> wrote:

IIUC, they're not entirely legacy, i.e. you at least put in the OSGi
manifest entries.  You do so using the maven/BND plugin I suspect.

 This strikes me as a common service discovery pattern.  Off the  
top of my
head I would think that a plugin that adds the necessary  
BundleActivator for

legacy modules would be useful.

 Another thought that flashed in my head is that in a buttoned down
environment getting service notifications might be easier than  
getting

access to every Bundle's class loader.


 Regards,
 Alan



 On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:


Cleaner, but the main problem is that it does not work with  
legacy code.
Will you rewrite the jaxb2 implementation to do that instead of  
using the

stax

factory ? ;-)
We've got tons of legacy stuff that use stax, or jaxb2 and i  
don't see

rewriting
the whole lot as realistic.  it would also mean having an OSGi  
specific

thing

everywhere we use a factory from a j2ee spec :-(

On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]>

wrote:





On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:




On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski

<[EMAIL PROTECTED]>



wrote:




On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet  
<[EMAIL PROTECTED]>





wrote:







However, lots of these spec jars define factories (stax, saaj  
for







example)






that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not

fit







well in






OSGi (really, it does not), mainly because usually, the

classloader

containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an

OSGi
BundleActivator that would change the behavior of these  
factories

when
deployed in an OSGi environment (without changing the  
behavior in







other






case).  The idea is that the activator would scan OSGi bundles

when







they are





started to find META-INF/services and populate a map that  
would be







used by






the factory when creating an object before using the standard






mechanism.










Just to ensure I'm following, you are about to create a activator

that

would be a bundle listener (o.o.f.BundleListener) and whenever a
bundle is registered the activator will scan it for provided

services?

Can you explain how osgi works now without these
META-INF/services-based services? Doesn't it use them at all?




This is the tricky part.  The work we've done on the specs so far
means that each spec
is an OSGi bundle.   In OSGi, each bundle has each own  
classloader and

classloaders
are not organized in a simple tree: if bundle A requires bundle  
B and

bundle B requires
bundle C, it does not mean that C will be accessible to A.   
Following

so



far ?


So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath.   
The stax

implementation that
I deploy will also have the stax api in its classpath, but it  
won't be

available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
implementation.
Usually, the existing code won't be able to do that at all,  
because

the META-INF/services
and the implementation class are not available from the stax api


classloader.


One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and  
make sure

the thread context
classloader is correctly set.  This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to  
make

sure the classloader
includes it.

The problem is that it's a bit annoying to do that on all the  
bundles

and it does prevent
swicthing implementations.

So now, there is

Re: Geronimo specs jars in OSGi

i don't mean legacy jars but legacy *code*.
If you have a jar which uses
  javax.xml.stream.XMLInputFactory.newInstance()
somewhere deep in the code, I don't really understand how using a whiteboard
pattern will solve the problem.  I'm not trying to make people rewrite
everything,
but rather make things easy for them to deploy their application and keep the
behavior they are used to see.
it could be you want to deploy the jaxws-ri, jersey or any other xml related
technology that could use SAAJ, Stax, Jaxb2 ...


On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> IIUC, they're not entirely legacy, i.e. you at least put in the OSGi
> manifest entries.  You do so using the maven/BND plugin I suspect.
>
>  This strikes me as a common service discovery pattern.  Off the top of my
> head I would think that a plugin that adds the necessary BundleActivator for
> legacy modules would be useful.
>
>  Another thought that flashed in my head is that in a buttoned down
> environment getting service notifications might be easier than getting
> access to every Bundle's class loader.
>
>
>  Regards,
>  Alan
>
>
>
>  On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:
>
>
> > Cleaner, but the main problem is that it does not work with legacy code.
> > Will you rewrite the jaxb2 implementation to do that instead of using the
> stax
> > factory ? ;-)
> > We've got tons of legacy stuff that use stax, or jaxb2 and i don't see
> rewriting
> > the whole lot as realistic.  it would also mean having an OSGi specific
> thing
> > everywhere we use a factory from a j2ee spec :-(
> >
> > On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera <[EMAIL PROTECTED]>
> wrote:
> >
> > >
> > >
> > > On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
> > >
> > >
> > >
> > > > On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski
> <[EMAIL PROTECTED]>
> > > >
> > > wrote:
> > >
> > > >
> > > >
> > > > > On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]>
> > > > >
> > > >
> > > wrote:
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > > However, lots of these spec jars define factories (stax, saaj for
> > > > > >
> > > > >
> > > >
> > > example)
> > >
> > > >
> > > > >
> > > > > > that use the META-INF/services/ discovery mechanism to find an
> > > > > > implementation of the spec and load it.  This mechanism does not
> fit
> > > > > >
> > > > >
> > > >
> > > well in
> > >
> > > >
> > > > >
> > > > > > OSGi (really, it does not), mainly because usually, the
> classloader
> > > > > > containing the spec jar will not contain the implementation.
> > > > > > I'd like to work on these spec jars so that they will contain an
> OSGi
> > > > > > BundleActivator that would change the behavior of these factories
> when
> > > > > > deployed in an OSGi environment (without changing the behavior in
> > > > > >
> > > > >
> > > >
> > > other
> > >
> > > >
> > > > >
> > > > > > case).  The idea is that the activator would scan OSGi bundles
> when
> > > > > >
> > > > >
> > > >
> > > they are
> > >
> > > >
> > > > >
> > > > > > started to find META-INF/services and populate a map that would be
> > > > > >
> > > > >
> > > >
> > > used by
> > >
> > > >
> > > > >
> > > > > > the factory when creating an object before using the standard
> > > > > >
> > > > >
> > > >
> > > mechanism.
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > Just to ensure I'm following, you are about to create a activator
> that
> > > > > would be a bundle listener (o.o.f.BundleListener) and whenever a
> > > > > bundle is registered the activator will scan it for provided
> services?
> > > > > Can you explain how osgi works now without these
> > > > > META-INF/services-based services? Doesn't it use them at all?
> > > > >
> > > > >
> > > >
> > > > This is the tricky part.  The work we've done on the specs so far
> > > > means that each spec
> > > > is an OSGi bundle.   In OSGi, each bundle has each own classloader and
> > > > classloaders
> > > > are not organized in a simple tree: if bundle A requires bundle B and
> > > > bundle B requires
> > > > bundle C, it does not mean that C will be accessible to A.  Following
> so
> > > >
> > > far ?
> > >
> > > > So, let's say I create a bundle that references the Stax Api.
> > > > My bundle will have the geronimo stax api in its classpath.  The stax
> > > > implementation that
> > > > I deploy will also have the stax api in its classpath, but it won't be
> > > > available to either
> > > > the the stax api or my bundle.
> > > > The problem happens when the stax api needs to find and create the
> > > > implementation.
> > > > Usually, the existing code won't be able to do that at all, because
> > > > the META-INF/services
> > > > and the implementation class are not available from the stax api
> > > >
> > > classloader.
> > >
> > > > One way to work around that is (if the api uses the thread context
> > > > classloader) to make sure
> > > > my bundle includes the implementation in its classlo

[jira] Commented: (GERONIMO-3960) Make the spec jars OSGi friendly

2008-04-17 Thread Alan Cabrera (JIRA)


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

Alan Cabrera commented on GERONIMO-3960:


What about bundle updates?  I don't think that this code will handle those 
situations.

> Make the spec jars OSGi friendly
> 
>
> Key: GERONIMO-3960
> URL: https://issues.apache.org/jira/browse/GERONIMO-3960
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Guillaume Nodet
> Attachments: stax-osgi.diff
>
>


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

[jira] Updated: (GERONIMO-3960) Make the spec jars OSGi friendly


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

Guillaume Nodet updated GERONIMO-3960:
--

Attachment: stax-osgi.diff

Examples of OSGi friendly spec for stax

> Make the spec jars OSGi friendly
> 
>
> Key: GERONIMO-3960
> URL: https://issues.apache.org/jira/browse/GERONIMO-3960
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Guillaume Nodet
> Attachments: stax-osgi.diff
>
>


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

Re: Geronimo specs jars in OSGi


Sorry.  This is for David's idea:

"I also wonder if there is a way to generalize the osgi method so it  
might work in some non-osgi environments."


Another reason to wrap the spec jar in a bundle is that we won't be  
seen as extending the spec, something that is explicitly prohibited in  
the licensing of the JSRs.



Regards,
Alan

On Apr 17, 2008, at 7:17 AM, Guillaume Nodet wrote:


Do you mean your -1 only apply to extending the behavior of the spec
in the J2EE environment,
and does not apply to extending the behavior in an OSGi environment ?
I'm not sure to completely understand your reasoning.

On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]> wrote:

Sorry, I meant to say:


On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote:




On Apr 16, 2008, at 8:49 AM, David Jencks wrote:


I'd like to see an example in action before I commit myself but  
so far I
don't see any problems with this.  I assume you have already or  
will soon

verify this doesn't cause problems with the tck :-)


I wonder if a package name with "osgi" in it somewhere would be  
more

appropriate?


There are some specs (jacc for instance) that use a system  
property to

figure out what to create.  I've always thought this was a less than
brilliant idea and wonder if we can do something similar for  
those.  I also
wonder if there is a way to generalize the osgi method so it might  
work in

some non-osgi environments.









-1 technical veto

These are spec jars and extending the behavior of these jars on an  
ad hoc
basis is bad and possibly violates the licenses of the JSRs they  
implement.



Regards,
Alan










--
Cheers,
Guillaume Nodet

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

[jira] Created: (GERONIMO-3960) Make the spec jars OSGi friendly

Make the spec jars OSGi friendly


 Key: GERONIMO-3960
 URL: https://issues.apache.org/jira/browse/GERONIMO-3960
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: specs
Reporter: Guillaume Nodet




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

Re: Geronimo specs jars in OSGi

IIUC, they're not entirely legacy, i.e. you at least put in the OSGi  
manifest entries.  You do so using the maven/BND plugin I suspect.


This strikes me as a common service discovery pattern.  Off the top of  
my head I would think that a plugin that adds the necessary  
BundleActivator for legacy modules would be useful.


Another thought that flashed in my head is that in a buttoned down  
environment getting service notifications might be easier than getting  
access to every Bundle's class loader.



Regards,
Alan

On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:

Cleaner, but the main problem is that it does not work with legacy  
code.
Will you rewrite the jaxb2 implementation to do that instead of  
using the stax

factory ? ;-)
We've got tons of legacy stuff that use stax, or jaxb2 and i don't  
see rewriting
the whole lot as realistic.  it would also mean having an OSGi  
specific thing

everywhere we use a factory from a j2ee spec :-(

On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]> wrote:



On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:


On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <[EMAIL PROTECTED] 
>

wrote:



On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]>

wrote:




However, lots of these spec jars define factories (stax, saaj for

example)

that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not  
fit

well in
OSGi (really, it does not), mainly because usually, the  
classloader

containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi
BundleActivator that would change the behavior of these  
factories when

deployed in an OSGi environment (without changing the behavior in

other
case).  The idea is that the activator would scan OSGi bundles  
when

they are

started to find META-INF/services and populate a map that would be

used by

the factory when creating an object before using the standard

mechanism.




Just to ensure I'm following, you are about to create a activator  
that

would be a bundle listener (o.o.f.BundleListener) and whenever a
bundle is registered the activator will scan it for provided  
services?

Can you explain how osgi works now without these
META-INF/services-based services? Doesn't it use them at all?



This is the tricky part.  The work we've done on the specs so far
means that each spec
is an OSGi bundle.   In OSGi, each bundle has each own classloader  
and

classloaders
are not organized in a simple tree: if bundle A requires bundle B  
and

bundle B requires
bundle C, it does not mean that C will be accessible to A.   
Following so

far ?

So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath.  The  
stax

implementation that
I deploy will also have the stax api in its classpath, but it  
won't be

available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
implementation.
Usually, the existing code won't be able to do that at all, because
the META-INF/services
and the implementation class are not available from the stax api

classloader.

One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and make  
sure

the thread context
classloader is correctly set.  This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to make
sure the classloader
includes it.

The problem is that it's a bit annoying to do that on all the  
bundles

and it does prevent
swicthing implementations.

So now, there is no need to reference the implementation from the
bundle.  The spec jar bundle
activator will use OSGi to find the META-INF/services/ entries each
time a bundle is installed
and if an implementation is used, will load the class through OSGi
API, using the implementation
bundle classloader instead of the spec jar classloader.



I think, just my personal opinion, that scouring bundles' META-INF/ 
services
entries is kinda klunky.  Could we not use a service/whiteboard  
approach

that is common in OSGi? When in Rome, do as the Romans do.

Let's assume that we go with the virgin spec jar wrapped in a bundle
paradigm I spoke of in a previous post.  Here the bundles that use  
the stax
api would register stax api service implementations.  The stax api  
would
catch those service registrations and properly configure the  
factory.   A

bit cleaner imo and you don't have to search every bundle.


Regards,
Alan






--
Cheers,
Guillaume Nodet

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

Re: Geronimo specs jars in OSGi

Cleaner, but the main problem is that it does not work with legacy code.
Will you rewrite the jaxb2 implementation to do that instead of using the stax
factory ? ;-)
We've got tons of legacy stuff that use stax, or jaxb2 and i don't see rewriting
the whole lot as realistic.  it would also mean having an OSGi specific thing
everywhere we use a factory from a j2ee spec :-(

On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>
>
>  On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
>
>
> > On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <[EMAIL PROTECTED]>
> wrote:
> >
> > > On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]>
> wrote:
> > >
> > >
> > > > However, lots of these spec jars define factories (stax, saaj for
> example)
> > > > that use the META-INF/services/ discovery mechanism to find an
> > > > implementation of the spec and load it.  This mechanism does not fit
> well in
> > > > OSGi (really, it does not), mainly because usually, the classloader
> > > > containing the spec jar will not contain the implementation.
> > > > I'd like to work on these spec jars so that they will contain an OSGi
> > > > BundleActivator that would change the behavior of these factories when
> > > > deployed in an OSGi environment (without changing the behavior in
> other
> > > > case).  The idea is that the activator would scan OSGi bundles when
> they are
> > > > started to find META-INF/services and populate a map that would be
> used by
> > > > the factory when creating an object before using the standard
> mechanism.
> > > >
> > >
> > > Just to ensure I'm following, you are about to create a activator that
> > > would be a bundle listener (o.o.f.BundleListener) and whenever a
> > > bundle is registered the activator will scan it for provided services?
> > > Can you explain how osgi works now without these
> > > META-INF/services-based services? Doesn't it use them at all?
> > >
> >
> > This is the tricky part.  The work we've done on the specs so far
> > means that each spec
> > is an OSGi bundle.   In OSGi, each bundle has each own classloader and
> > classloaders
> > are not organized in a simple tree: if bundle A requires bundle B and
> > bundle B requires
> > bundle C, it does not mean that C will be accessible to A.  Following so
> far ?
> > So, let's say I create a bundle that references the Stax Api.
> > My bundle will have the geronimo stax api in its classpath.  The stax
> > implementation that
> > I deploy will also have the stax api in its classpath, but it won't be
> > available to either
> > the the stax api or my bundle.
> > The problem happens when the stax api needs to find and create the
> > implementation.
> > Usually, the existing code won't be able to do that at all, because
> > the META-INF/services
> > and the implementation class are not available from the stax api
> classloader.
> > One way to work around that is (if the api uses the thread context
> > classloader) to make sure
> > my bundle includes the implementation in its classloader and make sure
> > the thread context
> > classloader is correctly set.  This usually involves copying the
> > META-INF/services/xx stuff
> > in our bundle and explicitely referencing the implementation to make
> > sure the classloader
> > includes it.
> >
> > The problem is that it's a bit annoying to do that on all the bundles
> > and it does prevent
> > swicthing implementations.
> >
> > So now, there is no need to reference the implementation from the
> > bundle.  The spec jar bundle
> > activator will use OSGi to find the META-INF/services/ entries each
> > time a bundle is installed
> > and if an implementation is used, will load the class through OSGi
> > API, using the implementation
> > bundle classloader instead of the spec jar classloader.
> >
>
>  I think, just my personal opinion, that scouring bundles' META-INF/services
> entries is kinda klunky.  Could we not use a service/whiteboard approach
> that is common in OSGi? When in Rome, do as the Romans do.
>
>  Let's assume that we go with the virgin spec jar wrapped in a bundle
> paradigm I spoke of in a previous post.  Here the bundles that use the stax
> api would register stax api service implementations.  The stax api would
> catch those service registrations and properly configure the factory.   A
> bit cleaner imo and you don't have to search every bundle.
>
>
>  Regards,
>  Alan
>
>



-- 
Cheers,
Guillaume Nodet

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

Re: Geronimo specs jars in OSGi



On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote:


I've thought about this.  The main problem is that you end up having
two different
jars for the spec, one being a plain jar and another one being an  
OSGi bundle.
Both would not be compatible if the bundle embeds the spec jar,  
because non osgi

environment would not be able to load the jar inside the bundle.
Imho, creating two different jars would confuse the users and be more
error prone.


Non OSGi environments use the vanilla jar as they currently do.  OSGi  
environments load the spec bundle.  Doesn't seem confusing to me.





On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera  
<[EMAIL PROTECTED]> wrote:


On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:




In the past months, I've been working on making the specs jars from

Geronimo working in an OSGi environment.

All these jars have been published and work great :-)
However, lots of these spec jars define factories (stax, saaj for  
example)

that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not  
fit well in

OSGi (really, it does not), mainly because usually, the classloader
containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi
BundleActivator that would change the behavior of these factories  
when
deployed in an OSGi environment (without changing the behavior in  
other
case).  The idea is that the activator would scan OSGi bundles when  
they are
started to find META-INF/services and populate a map that would be  
used by
the factory when creating an object before using the standard  
mechanism.


The only real difference compared to what we currently have would  
be the
addition of a package named org.apache.geronimo.specs.stax (for  
example)
that would contain the needed classes (i suppose two classes), and  
the
modification of the factories to delegate to one of these class  
before using
the standard behavior (the class would do nothing if not deployed  
in an OSGi

environment).

Has anyone any objection with such an enhancement in the specs jar ?



I would prefer to have a virgin spec jar wrapped inside an OSGi  
bundle.

Here the virgin factories would be overshadowed by the OSGi specific
factories.

I feel strongly about this but am willing to discuss it.


Regards,
Alan






--
Cheers,
Guillaume Nodet

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

Re: Geronimo specs jars in OSGi



On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:

On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <[EMAIL PROTECTED] 
> wrote:
On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]>  
wrote:


However, lots of these spec jars define factories (stax, saaj for  
example)

that use the META-INF/services/ discovery mechanism to find an
implementation of the spec and load it.  This mechanism does not  
fit well in

OSGi (really, it does not), mainly because usually, the classloader
containing the spec jar will not contain the implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi
BundleActivator that would change the behavior of these factories  
when
deployed in an OSGi environment (without changing the behavior in  
other
case).  The idea is that the activator would scan OSGi bundles  
when they are
started to find META-INF/services and populate a map that would be  
used by
the factory when creating an object before using the standard  
mechanism.


Just to ensure I'm following, you are about to create a activator  
that

would be a bundle listener (o.o.f.BundleListener) and whenever a
bundle is registered the activator will scan it for provided  
services?

Can you explain how osgi works now without these
META-INF/services-based services? Doesn't it use them at all?


This is the tricky part.  The work we've done on the specs so far
means that each spec
is an OSGi bundle.   In OSGi, each bundle has each own classloader and
classloaders
are not organized in a simple tree: if bundle A requires bundle B and
bundle B requires
bundle C, it does not mean that C will be accessible to A.   
Following so far ?

So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath.  The stax
implementation that
I deploy will also have the stax api in its classpath, but it won't be
available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
implementation.
Usually, the existing code won't be able to do that at all, because
the META-INF/services
and the implementation class are not available from the stax api  
classloader.

One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and make sure
the thread context
classloader is correctly set.  This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to make
sure the classloader
includes it.

The problem is that it's a bit annoying to do that on all the bundles
and it does prevent
swicthing implementations.

So now, there is no need to reference the implementation from the
bundle.  The spec jar bundle
activator will use OSGi to find the META-INF/services/ entries each
time a bundle is installed
and if an implementation is used, will load the class through OSGi
API, using the implementation
bundle classloader instead of the spec jar classloader.


I think, just my personal opinion, that scouring bundles' META-INF/ 
services entries is kinda klunky.  Could we not use a service/ 
whiteboard approach that is common in OSGi? When in Rome, do as the  
Romans do.


Let's assume that we go with the virgin spec jar wrapped in a bundle  
paradigm I spoke of in a previous post.  Here the bundles that use the  
stax api would register stax api service implementations.  The stax  
api would catch those service registrations and properly configure the  
factory.   A bit cleaner imo and you don't have to search every bundle.



Regards,
Alan

Re: [DISCUSS] Policy for granting write access to our Wiki

2008-04-17 Thread Hernan Cunico


Back on the check box option, we can customize Confluence so it includes an 
additional step (the check box) before enabling to save the page.

There are two approaches, one is to create a Confluence plugin to replace the 
current editpage.action and the other is to create a new custom editpage 
velocity macro and make some changes in Confluence configs to use this new 
functionality. In either case we'll need to ASF infra blessing to implement 
this change. I think all ASF projects using Confluence can benefit from this 
change.

Any velocity/confluence folk monitoring this thread that want to volunteer !?  
;-)  I'm just not having the spare cycles to investigate this more in detail.

Cheers!
Hernan

Joseph Leong wrote:
Just as Dan said, I think a lightweight process would be a good idea.  
Not to deter users from contributing, nor hinder those approving.  If we 
haven't had a problem with the Jira check-box format for IP reasons, 
this seems like not only a lightweight process but a familiar one at that.


-Joseph Leong

On Thu, Apr 17, 2008 at 8:37 AM, Kevan Miller <[EMAIL PROTECTED] 
> wrote:



On Apr 16, 2008, at 7:34 PM, Gianny Damour wrote:

I am supportive of Erik's suggestion. I am absolutely against a
process involving the submission of an iCLA.

Is a checkbox really required? Isn't a disclaimer enough to
protect IP rights?


Well, I think we can assume that a checkbox was a requirement for
Jira-based submissions (a disclaimer was not sufficient). Since,
Wiki submissions are essentially the same, I don't think a simple
disclaimer will be sufficient...

--kevan

Re: Geronimo specs jars in OSGi

I've thought about this.  The main problem is that you end up having
two different
jars for the spec, one being a plain jar and another one being an OSGi bundle.
Both would not be compatible if the bundle embeds the spec jar, because non osgi
environment would not be able to load the jar inside the bundle.
Imho, creating two different jars would confuse the users and be more
error prone.

On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>
>  On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
>
>
>
> > In the past months, I've been working on making the specs jars from
> Geronimo working in an OSGi environment.
> > All these jars have been published and work great :-)
> > However, lots of these spec jars define factories (stax, saaj for example)
> that use the META-INF/services/ discovery mechanism to find an
> implementation of the spec and load it.  This mechanism does not fit well in
> OSGi (really, it does not), mainly because usually, the classloader
> containing the spec jar will not contain the implementation.
> > I'd like to work on these spec jars so that they will contain an OSGi
> BundleActivator that would change the behavior of these factories when
> deployed in an OSGi environment (without changing the behavior in other
> case).  The idea is that the activator would scan OSGi bundles when they are
> started to find META-INF/services and populate a map that would be used by
> the factory when creating an object before using the standard mechanism.
> >
> > The only real difference compared to what we currently have would be the
> addition of a package named org.apache.geronimo.specs.stax (for example)
> that would contain the needed classes (i suppose two classes), and the
> modification of the factories to delegate to one of these class before using
> the standard behavior (the class would do nothing if not deployed in an OSGi
> environment).
> > Has anyone any objection with such an enhancement in the specs jar ?
> >
>
>  I would prefer to have a virgin spec jar wrapped inside an OSGi bundle.
> Here the virgin factories would be overshadowed by the OSGi specific
> factories.
>
>  I feel strongly about this but am willing to discuss it.
>
>
>  Regards,
>  Alan
>
>



-- 
Cheers,
Guillaume Nodet

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

Re: Geronimo specs jars in OSGi

Do you mean your -1 only apply to extending the behavior of the spec
in the J2EE environment,
and does not apply to extending the behavior in an OSGi environment ?
I'm not sure to completely understand your reasoning.

On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> Sorry, I meant to say:
>
>
>  On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote:
>
>
> >
> > On Apr 16, 2008, at 8:49 AM, David Jencks wrote:
> >
> >
> > > I'd like to see an example in action before I commit myself but so far I
> don't see any problems with this.  I assume you have already or will soon
> verify this doesn't cause problems with the tck :-)
> > >
> > > I wonder if a package name with "osgi" in it somewhere would be more
> appropriate?
> > >
> > > There are some specs (jacc for instance) that use a system property to
> figure out what to create.  I've always thought this was a less than
> brilliant idea and wonder if we can do something similar for those.  I also
> wonder if there is a way to generalize the osgi method so it might work in
> some non-osgi environments.
> > >
> >
>
>
>
> > -1 technical veto
> >
> > These are spec jars and extending the behavior of these jars on an ad hoc
> basis is bad and possibly violates the licenses of the JSRs they implement.
> >
> >
> > Regards,
> > Alan
> >
> >
> >
>
>



-- 
Cheers,
Guillaume Nodet

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

Re: Geronimo specs jars in OSGi


Sorry, I meant to say:

On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote:



On Apr 16, 2008, at 8:49 AM, David Jencks wrote:

I'd like to see an example in action before I commit myself but so  
far I don't see any problems with this.  I assume you have already  
or will soon verify this doesn't cause problems with the tck :-)


I wonder if a package name with "osgi" in it somewhere would be  
more appropriate?


There are some specs (jacc for instance) that use a system property  
to figure out what to create.  I've always thought this was a less  
than brilliant idea and wonder if we can do something similar for  
those.  I also wonder if there is a way to generalize the osgi  
method so it might work in some non-osgi environments.



-1 technical veto

These are spec jars and extending the behavior of these jars on an  
ad hoc basis is bad and possibly violates the licenses of the JSRs  
they implement.



Regards,
Alan

Re: Geronimo specs jars in OSGi



On Apr 16, 2008, at 8:49 AM, David Jencks wrote:

I'd like to see an example in action before I commit myself but so  
far I don't see any problems with this.  I assume you have already  
or will soon verify this doesn't cause problems with the tck :-)


I wonder if a package name with "osgi" in it somewhere would be more  
appropriate?


There are some specs (jacc for instance) that use a system property  
to figure out what to create.  I've always thought this was a less  
than brilliant idea and wonder if we can do something similar for  
those.  I also wonder if there is a way to generalize the osgi  
method so it might work in some non-osgi environments.  I'm looking  
forward to seeing what you have in mind.


thanks
david jencks

On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
In the past months, I've been working on making the specs jars from  
Geronimo working in an OSGi environment.

All these jars have been published and work great :-)
However, lots of these spec jars define factories (stax, saaj for  
example) that use the META-INF/services/ discovery mechanism to  
find an implementation of the spec and load it.  This mechanism  
does not fit well in OSGi (really, it does not), mainly because  
usually, the classloader containing the spec jar will not contain  
the implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi BundleActivator that would change the behavior of these  
factories when deployed in an OSGi environment (without changing  
the behavior in other case).  The idea is that the activator would  
scan OSGi bundles when they are started to find META-INF/services  
and populate a map that would be used by the factory when creating  
an object before using the standard mechanism.


The only real difference compared to what we currently have would  
be the addition of a package named org.apache.geronimo.specs.stax  
(for example) that would contain the needed classes (i suppose two  
classes), and the modification of the factories to delegate to one  
of these class before using the standard behavior (the class would  
do nothing if not deployed in an OSGi environment).

Has anyone any objection with such an enhancement in the specs jar ?


-1 technical veto

These are spec jars and extending the behavior of these jars on an ad  
hoc basis is bad and possibly violates the licenses of the JSRs they  
implement.



Regards,
Alan

Re: Geronimo specs jars in OSGi



On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:

In the past months, I've been working on making the specs jars from  
Geronimo working in an OSGi environment.

All these jars have been published and work great :-)
However, lots of these spec jars define factories (stax, saaj for  
example) that use the META-INF/services/ discovery mechanism to find  
an implementation of the spec and load it.  This mechanism does not  
fit well in OSGi (really, it does not), mainly because usually, the  
classloader containing the spec jar will not contain the  
implementation.
I'd like to work on these spec jars so that they will contain an  
OSGi BundleActivator that would change the behavior of these  
factories when deployed in an OSGi environment (without changing the  
behavior in other case).  The idea is that the activator would scan  
OSGi bundles when they are started to find META-INF/services and  
populate a map that would be used by the factory when creating an  
object before using the standard mechanism.


The only real difference compared to what we currently have would be  
the addition of a package named org.apache.geronimo.specs.stax (for  
example) that would contain the needed classes (i suppose two  
classes), and the modification of the factories to delegate to one  
of these class before using the standard behavior (the class would  
do nothing if not deployed in an OSGi environment).

Has anyone any objection with such an enhancement in the specs jar ?


I would prefer to have a virgin spec jar wrapped inside an OSGi  
bundle. Here the virgin factories would be overshadowed by the OSGi  
specific factories.


I feel strongly about this but am willing to discuss it.


Regards,
Alan

Re: Geronimo specs jars in OSGi

2008-04-17 Thread Daniel Kulp

On Thursday 17 April 2008, Jacek Laskowski wrote:
> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]> 
wrote:
> > However, lots of these spec jars define factories (stax, saaj for
> > example) that use the META-INF/services/ discovery mechanism to find
> > an implementation of the spec and load it.  This mechanism does not
> > fit well in OSGi (really, it does not), mainly because usually, the
> > classloader containing the spec jar will not contain the
> > implementation. I'd like to work on these spec jars so that they
> > will contain an OSGi BundleActivator that would change the behavior
> > of these factories when deployed in an OSGi environment (without
> > changing the behavior in other case).  The idea is that the
> > activator would scan OSGi bundles when they are started to find
> > META-INF/services and populate a map that would be used by the
> > factory when creating an object before using the standard mechanism.
>
> Just to ensure I'm following, you are about to create a activator that
> would be a bundle listener (o.o.f.BundleListener) and whenever a
> bundle is registered the activator will scan it for provided services?
> Can you explain how osgi works now without these
> META-INF/services-based services? Doesn't it use them at all?

I'll provide an example that I'm running into   In my OSGi app, if I 
do something like MessageFactory.newInstance() to create a new SAAJ 
MessageFactory, the current spec implementations check the 
contextClassLoader for the 
META-INF/services/javax.xml.soap.MessageFactory file.  Outside of OSGi, 
that would be properly picked up from the implementation jar.   Inside 
OSGi, the file isn't available, so it defaults to whatever version is 
hardcoded into the saaj-api jar, which may not even be available.  
Basically, in OSGi, you cannot have multiple jars/bundles export the 
META-INF/services directory.   That won't work.  Thus, the whole 
META-INF/services thing that all the specs rely on just doesn't work.  
(IMO: this is a big deficiency in the OSGi spec, but that's my opinion)

The goal is to allow the "default" that is hard coded into the saaj-api 
jar to be replaced/augmented at runtime based on information the bundle 
listener finds in the other bundles that are available.  Thus, when we 
call MessageFactory.newInstance(), it would probably still check 
META-INF/services/javax.xml.soap.MessageFactory (so someone COULD put 
that in their application bundle and possibly get it), but if not found, 
use a default value that can actually have a chance of succeeding.

Dan

>
> > The only real difference compared to what we currently have would be
> > the addition of a package named org.apache.geronimo.specs.stax (for
> > example) that would contain the needed classes (i suppose two
> > classes), and the modification of the factories to delegate to one
> > of these class before using the standard behavior (the class would
> > do nothing if not deployed in an OSGi environment).
> >  Has anyone any objection with such an enhancement in the specs jar
> > ?
>
> Unless I'm mistaken it shouldn't cause any troubles on non-osgi
> environments and big +1 for the upcoming changes.
>
> Jacek

-- 
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Re: Geronimo specs jars in OSGi

On Wed, Apr 16, 2008 at 5:49 PM, David Jencks <[EMAIL PROTECTED]> wrote:
>  I'd like to see an example in action before I commit myself but so far I
> don't see any problems with this.  I assume you have already or will soon
> verify this doesn't cause problems with the tck :-)

Fair enough ;-)  I may ping someone, as I've never worked on the TCK so far.

>
> I wonder if a package name with "osgi" in it somewhere would be more
> appropriate?

Agreed.

>
> There are some specs (jacc for instance) that use a system property to
> figure out what to create.  I've always thought this was a less than
> brilliant idea and wonder if we can do something similar for those.  I also
> wonder if there is a way to generalize the osgi method so it might work in
> some non-osgi environments.  I'm looking forward to seeing what you have in
> mind.

I guess you are talking about the PolicyConfigurationFactory in jacc.
I suppose we could extend the mechanism to include searching through
the META-INF/services/xxx stuff instead of simply relying on a system property.
However, the mechanism I'm thinking about is quite specific to OSGi (at least
in its implementation).


>
> thanks
> david jencks
>
>
> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
> In the past months, I've been working on making the specs jars from Geronimo
> working in an OSGi environment.
> All these jars have been published and work great :-)
> However, lots of these spec jars define factories (stax, saaj for example)
> that use the META-INF/services/ discovery mechanism to find an
> implementation of the spec and load it.  This mechanism does not fit well in
> OSGi (really, it does not), mainly because usually, the classloader
> containing the spec jar will not contain the implementation.
>  I'd like to work on these spec jars so that they will contain an OSGi
> BundleActivator that would change the behavior of these factories when
> deployed in an OSGi environment (without changing the behavior in other
> case).  The idea is that the activator would scan OSGi bundles when they are
> started to find META-INF/services and populate a map that would be used by
> the factory when creating an object before using the standard mechanism.
>
> The only real difference compared to what we currently have would be the
> addition of a package named org.apache.geronimo.specs.stax (for example)
> that would contain the needed classes (i suppose two classes), and the
> modification of the factories to delegate to one of these class before using
> the standard behavior (the class would do nothing if not deployed in an OSGi
> environment).
>  Has anyone any objection with such an enhancement in the specs jar ?
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
>



-- 
Cheers,
Guillaume Nodet

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

Re: Geronimo specs jars in OSGi

On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>
>  > However, lots of these spec jars define factories (stax, saaj for example)
>  > that use the META-INF/services/ discovery mechanism to find an
>  > implementation of the spec and load it.  This mechanism does not fit well 
> in
>  > OSGi (really, it does not), mainly because usually, the classloader
>  > containing the spec jar will not contain the implementation.
>  >  I'd like to work on these spec jars so that they will contain an OSGi
>  > BundleActivator that would change the behavior of these factories when
>  > deployed in an OSGi environment (without changing the behavior in other
>  > case).  The idea is that the activator would scan OSGi bundles when they 
> are
>  > started to find META-INF/services and populate a map that would be used by
>  > the factory when creating an object before using the standard mechanism.
>
>  Just to ensure I'm following, you are about to create a activator that
>  would be a bundle listener (o.o.f.BundleListener) and whenever a
>  bundle is registered the activator will scan it for provided services?
>  Can you explain how osgi works now without these
>  META-INF/services-based services? Doesn't it use them at all?

This is the tricky part.  The work we've done on the specs so far
means that each spec
is an OSGi bundle.   In OSGi, each bundle has each own classloader and
classloaders
are not organized in a simple tree: if bundle A requires bundle B and
bundle B requires
bundle C, it does not mean that C will be accessible to A.  Following so far ?
So, let's say I create a bundle that references the Stax Api.
My bundle will have the geronimo stax api in its classpath.  The stax
implementation that
I deploy will also have the stax api in its classpath, but it won't be
available to either
the the stax api or my bundle.
The problem happens when the stax api needs to find and create the
implementation.
Usually, the existing code won't be able to do that at all, because
the META-INF/services
and the implementation class are not available from the stax api classloader.
One way to work around that is (if the api uses the thread context
classloader) to make sure
my bundle includes the implementation in its classloader and make sure
the thread context
classloader is correctly set.  This usually involves copying the
META-INF/services/xx stuff
in our bundle and explicitely referencing the implementation to make
sure the classloader
includes it.

The problem is that it's a bit annoying to do that on all the bundles
and it does prevent
swicthing implementations.

So now, there is no need to reference the implementation from the
bundle.  The spec jar bundle
activator will use OSGi to find the META-INF/services/ entries each
time a bundle is installed
and if an implementation is used, will load the class through OSGi
API, using the implementation
bundle classloader instead of the spec jar classloader.

>
>
>  > The only real difference compared to what we currently have would be the
>  > addition of a package named org.apache.geronimo.specs.stax (for example)
>  > that would contain the needed classes (i suppose two classes), and the
>  > modification of the factories to delegate to one of these class before 
> using
>  > the standard behavior (the class would do nothing if not deployed in an 
> OSGi
>  > environment).
>  >  Has anyone any objection with such an enhancement in the specs jar ?
>
>  Unless I'm mistaken it shouldn't cause any troubles on non-osgi
>  environments and big +1 for the upcoming changes.

Exactly, the behavior should be exactly the same in non OSGi environment.

>
>  Jacek
>
>  --
>  Jacek Laskowski
>  http://www.JacekLaskowski.pl
>

-- 
Cheers,
Guillaume Nodet

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

[jira] Commented: (GERONIMO-3959) Freeze during deploying OrderEAR sample from GMOxDOC21

2008-04-17 Thread Kevan Miller (JIRA)


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

Kevan Miller commented on GERONIMO-3959:


Wow. Thanks for pointing this out...

Here's the culprit:

"RMI TCP Connection(5)-0:0:0:0:a01:0:efe1:5803%266" daemon prio=5 
tid=0x11c44420 nid=0x935400 runnable [0xb1a23000..0xb1a25d90]
at java.lang.Class.getClassLoader0(Native Method)
at java.lang.ClassLoader.getCallerClassLoader(ClassLoader.java:1411)
at java.lang.Class.getDeclaredMethods(Class.java:1762)
at 
org.apache.openejb.config.rules.CheckCallbacks.getMethods(CheckCallbacks.java:197)
at 
org.apache.openejb.config.rules.CheckCallbacks.checkCallback(CheckCallbacks.java:169)
at 
org.apache.openejb.config.rules.CheckCallbacks.validate(CheckCallbacks.java:86)
at 
org.apache.openejb.config.rules.ValidationBase.validate(ValidationBase.java:43)
at org.apache.openejb.config.AppValidator.validate(AppValidator.java:82)
at 
org.apache.openejb.config.ValidateModules.deploy(ValidateModules.java:31)
at 
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:141)
at 
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:425)
at 
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.configureApplication(EjbModuleBuilder.java:638)
at 
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.getEjbJarInfo(EjbModuleBuilder.java:575)
at 
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.initContext(EjbModuleBuilder.java:497)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at 
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
at 
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at 
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172)
at 
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
at 
javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
at 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
at java.security.AccessController.doPrivileged(Native Method)
at 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1350)
at 
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.sec

Re: [DISCUSS] Policy for granting write access to our Wiki

2008-04-17 Thread Joseph Leong

Just as Dan said, I think a lightweight process would be a good idea.  Not
to deter users from contributing, nor hinder those approving.  If we haven't
had a problem with the Jira check-box format for IP reasons, this seems like
not only a lightweight process but a familiar one at that.

-Joseph Leong

On Thu, Apr 17, 2008 at 8:37 AM, Kevan Miller <[EMAIL PROTECTED]>
wrote:

>
> On Apr 16, 2008, at 7:34 PM, Gianny Damour wrote:
>
>  I am supportive of Erik's suggestion. I am absolutely against a process
> > involving the submission of an iCLA.
> >
> > Is a checkbox really required? Isn't a disclaimer enough to protect IP
> > rights?
> >
>
> Well, I think we can assume that a checkbox was a requirement for
> Jira-based submissions (a disclaimer was not sufficient). Since, Wiki
> submissions are essentially the same, I don't think a simple disclaimer will
> be sufficient...
>
> --kevan
>
>

[jira] Updated: (GERONIMO-3930) IllegalArgumentException reading Transaction Log

2008-04-17 Thread Joe Bohn (JIRA)


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

Joe Bohn updated GERONIMO-3930:
---

Fix Version/s: (was: 2.1.1)
   2.1.x

Kevan,
It appears this issue will not be resolved for 2.1.1 so I'm moving the fix 
version to 2.1.x.  
Joe

> IllegalArgumentException reading Transaction Log
> 
>
> Key: GERONIMO-3930
> URL: https://issues.apache.org/jira/browse/GERONIMO-3930
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Kevan Miller
>Priority: Critical
> Fix For: 2.0.x, 2.1.x, 2.2
>
>
> Beniamin has reported the following problem on [EMAIL PROTECTED]
> After processing 20k request to my webservice whose are translated to ~120k
> XA transactions (postgres  + jms) Geronimo hangs up and does not respond on
> requests via HTTP, request to JMS engine (from HermesJMS) and ignores tries
> to shutdown server.
> I stopped Geronimo with kill -9 and tried to start it again and got
> exception:
> Module 11/69 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car
> 10:22:15,325 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state:
> abstractName="org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car,j2eeType=TransactionLog,name=HOWLTransactionLog"
> java.lang.IllegalArgumentException: Negative position
>at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:613)
>at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:412)
>at org.objectweb.howl.log.LogFileManager.read(LogFileManager.java:641)
>at 
> org.objectweb.howl.log.LogBufferManager.replay(LogBufferManager.java:869)
>at org.objectweb.howl.log.Logger.replay(Logger.java:396)
>at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:897)
>at 
> org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:224)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539)
>at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
>at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
>at 
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
>at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
>at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
>at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553)
>at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
>at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448)
>at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
>at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at 
> org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
>at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
>at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
>at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at 
> org.apache.geronimo.kernel.basic.RawOperationInvoke

[jira] Updated: (GERONIMO-3900) Add runtime support for non-Sun JVMs

2008-04-17 Thread Joe Bohn (JIRA)


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

Joe Bohn updated GERONIMO-3900:
---

Fix Version/s: (was: 2.1.1)
   2.1.x

Donald,
I have to assume that this issue is not yet resolved for 2.1.1.  If it is in 
fact resolved, please correct the fix version and mark it as resolved.  
Thanks, Joe

> Add runtime support for non-Sun JVMs
> 
>
> Key: GERONIMO-3900
> URL: https://issues.apache.org/jira/browse/GERONIMO-3900
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: common
>Affects Versions: 1.x, 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Donald Woods
>Assignee: Donald Woods
> Fix For: 2.0.x, 2.1.x, 2.2
>
>
> Add support for non-Sun JVMs.
> The IBM JVM needs a different cert handler setup.
> Will also add initial Harmony support, which will need to be refined once the 
> TCK is running against it.
> Will reuse the SystemProperties GBean, but extend it to support Sun vs. IBM 
> vs. Harmony specific property settings.
> Will also add a JvmVendor class, to properly detect the JVM being used at 
> runtime.

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

[jira] Updated: (GERONIMO-3959) Freeze during deploying OrderEAR sample from GMOxDOC21

2008-04-17 Thread JIRA


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

Michał Kudła updated GERONIMO-3959:
---

Attachment: GMOxDOC21_Order.zip

- sources,
- binaries,
- geronimo logs

> Freeze during deploying OrderEAR sample from GMOxDOC21 
> ---
>
> Key: GERONIMO-3959
> URL: https://issues.apache.org/jira/browse/GERONIMO-3959
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.1
> Environment: Gentoo Linux 2.6.22, Java IBM J9 2.4 Linux x86-32 
> jvmxi3260-20071121_15015
>Reporter: Michał Kudła
>Priority: Blocker
> Attachments: GMOxDOC21_Order.zip
>
>
> I created EAR according to 
> http://cwiki.apache.org/GMOxDOC21/deployment-plans.html.
> But, unedr deployment, Geronimo stoped without any messages.

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

Re: remote ejb scalability issue

2008-04-17 Thread Kevan Miller



On Apr 17, 2008, at 8:31 AM, Gianny Damour wrote:


Hi,

It would be great to have only one TCP/IP connection opened between  
an EJB client and the EJB server and this across multiple requests.  
My understanding is that at the moment a TCP/IP connection is  
negotiated for each EJB request which is very expensive especially  
based on the rather small size of the payload being passed back and  
forth over TCP/IP.


Definitely agree it's something to look into. I had thought about  
that, but got focussed on getting this guy past his immediate problem.


You should make this suggestion on [EMAIL PROTECTED]

--kevan

[jira] Created: (GERONIMO-3959) Freeze during deploying OrderEAR sample from GMOxDOC21

2008-04-17 Thread JIRA

Freeze during deploying OrderEAR sample from GMOxDOC21 
---

 Key: GERONIMO-3959
 URL: https://issues.apache.org/jira/browse/GERONIMO-3959
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 2.1
 Environment: Gentoo Linux 2.6.22, Java IBM J9 2.4 Linux x86-32 
jvmxi3260-20071121_15015
Reporter: Michał Kudła
Priority: Blocker


I created EAR according to 
http://cwiki.apache.org/GMOxDOC21/deployment-plans.html.
But, unedr deployment, Geronimo stoped without any messages.


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

Re: [DISCUSS] Policy for granting write access to our Wiki

2008-04-17 Thread Kevan Miller



On Apr 16, 2008, at 7:34 PM, Gianny Damour wrote:

I am supportive of Erik's suggestion. I am absolutely against a  
process involving the submission of an iCLA.


Is a checkbox really required? Isn't a disclaimer enough to protect  
IP rights?


Well, I think we can assume that a checkbox was a requirement for Jira- 
based submissions (a disclaimer was not sufficient). Since, Wiki  
submissions are essentially the same, I don't think a simple  
disclaimer will be sufficient...


--kevan

Re: remote ejb scalability issue

2008-04-17 Thread Gianny Damour


Hi,

It would be great to have only one TCP/IP connection opened between  
an EJB client and the EJB server and this across multiple requests.  
My understanding is that at the moment a TCP/IP connection is  
negotiated for each EJB request which is very expensive especially  
based on the rather small size of the payload being passed back and  
forth over TCP/IP.


Thanks,
Gianny

On 17/04/2008, at 12:27 PM, Kevan Miller wrote:



On Apr 16, 2008, at 6:30 PM, Trygve Hardersen wrote:

I checked out the 2.1.1 branch that is using openejb 3.0, but I'm
still getting the error. It seems less frequent though, but it's  
still

bad. The stack trace is different, but the root cause is the same:


Hi Trygve,
I'm guessing that you're running on a Windows? I've only seen this  
type of error happen on a Windows. Note that this is a client  
socket (not a server socket). We aren't assigning the port  
address... It's being assigned to the socket dynamically.


One possibility is that you are exhausting the available user port  
numbers. When a socket is closed, it goes into a TIME_WAIT state  
and isn't actual closed until some delay time. By default, the max  
user port address is 5000 and the TIME_WAIT delay is 4 minutes. So,  
it's not too difficult to exhaust all possible user port addresses.


You have to update the Windows Registry to change these values.  
Here's a Windows 2000 doc on the registry settings -- http:// 
technet.microsoft.com/en-us/library/bb726981.aspx


MaxUserPorts controls the upper range for user ports.
TcpTimedWaitDelay controls the TIME_WAIT delay.

Hopefully, increasing MaxUserPorts (e.g. 65534) and decreasing  
TcpTimedWaitDelay (e.g. 30)will fix your problem.


If not, then I also recall a problem where Windows would assign the  
same dynamic port address to 2 (or more) newly created sockets. It  
was then a race to see which one would be activated first and the  
other one would get a bind failure. Not sure there's anything we  
can do about that...


--kevan

Re: Geronimo specs jars in OSGi

2008-04-17 Thread Jacek Laskowski

On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote:

> However, lots of these spec jars define factories (stax, saaj for example)
> that use the META-INF/services/ discovery mechanism to find an
> implementation of the spec and load it.  This mechanism does not fit well in
> OSGi (really, it does not), mainly because usually, the classloader
> containing the spec jar will not contain the implementation.
>  I'd like to work on these spec jars so that they will contain an OSGi
> BundleActivator that would change the behavior of these factories when
> deployed in an OSGi environment (without changing the behavior in other
> case).  The idea is that the activator would scan OSGi bundles when they are
> started to find META-INF/services and populate a map that would be used by
> the factory when creating an object before using the standard mechanism.

Just to ensure I'm following, you are about to create a activator that
would be a bundle listener (o.o.f.BundleListener) and whenever a
bundle is registered the activator will scan it for provided services?
Can you explain how osgi works now without these
META-INF/services-based services? Doesn't it use them at all?

> The only real difference compared to what we currently have would be the
> addition of a package named org.apache.geronimo.specs.stax (for example)
> that would contain the needed classes (i suppose two classes), and the
> modification of the factories to delegate to one of these class before using
> the standard behavior (the class would do nothing if not deployed in an OSGi
> environment).
>  Has anyone any objection with such an enhancement in the specs jar ?

Unless I'm mistaken it shouldn't cause any troubles on non-osgi
environments and big +1 for the upcoming changes.

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: [DISCUSS] Policy for granting write access to our Wiki

2008-04-17 Thread Gianny Damour

I am supportive of Erik's suggestion. I am absolutely against a  
process involving the submission of an iCLA.


Is a checkbox really required? Isn't a disclaimer enough to protect  
IP rights?


Thanks,
Gianny


On 17/04/2008, at 4:01 AM, Jason Warner wrote:
I'd be more inclined to do something akin to what Erik suggested.   
I'm concerned that the process to gain access to editing the wiki  
would deter many of the people that add a page here and there that  
describes something they've done.  A number of our contributions  
come from people who are just making a one time edit.  I can't  
imagine many of them would go through the effort to gain  
contributor access to add a single page.


On Wed, Apr 16, 2008 at 1:57 PM, Erik B. Craig <[EMAIL PROTECTED]>  
wrote:
I agree that we definitely need to address IP issues around  
documentation/the wiki... but isn't there any way to accomplish  
this without adding barriers to users editing content?
Can we do something like wikipedia does for editing content where  
there is a checkbox or a notice or something saying
"You agree to license your contributions under the Apache Software  
License" (similar to how JIRA is currently)



--
Erik B. Craig

On Wed, Apr 16, 2008 at 9:00 AM, Kevan Miller  
<[EMAIL PROTECTED]> wrote:

All,
To properly protect the IP rights of our Wiki-based documentation,  
we need to stop allowing unrestricted write access to our Wiki.  
Wiki contributors should be required to have an ICLA on file with  
the ASF. I also think that we need to hold a PMC vote before  
granting this access.


I'll also take this opportunity to remind the community that Wiki  
updates are sent to [EMAIL PROTECTED] These updates need to  
be reviewed by the community, just like all code updates.


IMO, we don't want this to be a heavy-weight process. We don't want  
there to be a significant hurdle to contributing documentation. For  
code updates, patch files attached to Jira's with the "Grant  
license to ASF" button checked takes care of these IP concerns. To  
my knowledge, there's no patch file equivalent for updates to a  
Wiki. We could require that documentation updates be contributed in  
the form of simple ascii text files that are attached to a Jira.  
This would address our IP concerns, but is not ideal IMO.


To keep this as light-weight as possible, I propose we formalize  
the concept of "contributor". A contributor would have write access  
to our Wiki documentation as well as the ability to assign Jira's  
to him/herself.


I think the process would go something like this...

0. Reset write access to our wiki to be only the current set of  
committers on the project.


1. New documentation contributions from non-committers/contributors  
must be submitted via a Jira, with the "Grant License to the ASF"  
box checked. This is just like any code/bug-fix submission.


2. Once a new participant has expressed interest in contributing to  
the project and/or has contributed documentation or bug fixes, a  
PMC vote will be called to grant the new participant "contributor"  
rights. As all PMC votes, this vote is a majority vote, require a  
minimum of 3 +1 votes, and will last for a minimum of 72 hours.


3. Once a vote has passed, the participant will be invited to join  
the project as a 'contributor'.  Assuming he/she accepts, the  
participant must then submit an ICLA to the ASF.
Once the ICLA is on file, the new 'contributor' will give given  
write access to our wiki and the ability to assign Jira's.


4. The new contributor will be announced to the community.

I've grouped Jira rights with wiki rights in the above. This is not  
strictly necessary, but grouping the two seems like a reasonable step.


This is my first pass at a proposal. We can tweak this process in a  
number of ways and there are alternatives. I think the hard  
requirements are 1) the PMC must vote and 2) an ICLA must be filed  
with the ASF.


Until we resolve this issue, we need to restrict Wiki write access  
to be the current set of Geronimo committers.


--kevan






--
~Jason Warner

[BUILD] trunk: Failed for Revision: 648985

2008-04-17 Thread gawor

Geronimo Revision: 648985 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417/build-0300.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 32 minutes 6 seconds
[INFO] Finished at: Thu Apr 17 03:59:28 EDT 2008
[INFO] Final Memory: 330M/732M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417/logs-0300-tomcat/test.log
 
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417/logs-0300-jetty/test.log
 
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 74.027 
sec <<< FAILURE!
 
Samples: trunk
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417/samples-0300.log
 
Build status: OK

Re: [DISCUSS] GEP 2.1 support for v1.1

2008-04-17 Thread Shiva Kumar H R

So are we finally going in for #3? If yes, we must drop v1.1 plug-ins before
we release GEP 2.1.0 as most of them may not be working as expected!

On Sat, Mar 29, 2008 at 11:49 AM, Tim McConnell <[EMAIL PROTECTED]>
wrote:

> Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the
> 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are
> now working and we are much better positioned to handle future schema
> changes in a more timely manner. Traditionally, the GEP has supported 3 to 4
> versions of the Geronimo server (primarily to provide a migration/upgrade
> path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x.
> However, since we are almost 2 months behind the release of the v2.1
> Geronimo server I would like to discuss some possible alternatives for
> supporting the v1.1 Geronimo server in this release of the GEP:
>
> #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously
> the most expensive in terms of time and testing required)
>
> #2. Leave the v1.1 support in the current EMF implementation (i.e., the
> JAXB and EMF implementations would co-exist)
>
> #3. Remove support altogether for v1.1 in this release of the GEP --
> support only the v2.0 and v2.1 Geronimo servers (the least expensive in
> terms of time and testing required)
>
> I'm now of the opinion that we should pursue alternative #3 and remove
> v1.1 support entirely. My primary rationale is that the the old 2.0 release
> of the GEP can still be used to provide v1.1 server support, and still
> provides a migration path from v1.1 to v2.0. It's true that we would lose
> the v1.1 to v2.1 migration path, but this is mitigated somewhat since the
> support in the GEP for the v2.0 and v2.1 versions of the server is almost
> identical. Equally important is that we could then focus entirely on fixing
> the few remaining JIRAs and augmenting our JUnit testcases, and release the
> GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ??
>
> --
> Thanks,
> Tim McConnell
>



-- 
Thanks,
Shiva

[jira] Closed: (GERONIMO-3705) Maven 2.0.8 causes build problems