[jira] Created: (GERONIMO-3486) GBean order makes security work?

[Jarek Gawor (JIRA)]

GBean order makes security work?


 Key: GERONIMO-3486
 URL: https://issues.apache.org/jira/browse/GERONIMO-3486
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Jarek Gawor


I was trying to fix the testsuite/enterprise-testsuite/sec-tests tests. 
Initially, the test were failing with 
"javax.security.auth.login.LoginException: No LoginModules configured". After 
trying a few things, I switched the order of GBeans in the deployment plan and 
that made the tests pass. See 
http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/enterprise-testsuite/sec-tests/sec-ejb/src/main/resources/META-INF/openejb-jar.xml?r1=560771&r2=579469.
 
I'm not sure if this is a bug or not. 


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

Re: MEJB Question

[David Blevins]

On Sep 25, 2007, at 8:44 AM, Anita Kulshreshtha wrote:


   Right now I am stuck at this:
   @RolesAllowed({a, b})
   public class . {
   @RolesAllowed(b) {
   public .. dosomething() {
   }
   }
   Does this prevent 'a' from accessing dosomething()?



Yes.  See http://openejb.apache.org/security-annotations.html

-David

Re: Adding j2g to site

[Jason Warner]

Tim,

Quick thought.  There are pages on the geronimo wiki that contain
installation instructions[1] and usage instructions[2].  Those links could
be placed under the appropriate headings on the "Apache Geronimo Development
Tools Subproject" website.  Thoughts?

[1] http://cwiki.apache.org/GMOxDOC20/building-j2g-from-source.html

[2] http://cwiki.apache.org/GMOxDOC11/using-j2g.html

Thanks,

Jason Warner

On 9/25/07, Jason Warner <[EMAIL PROTECTED]> wrote:
>
>
>
> On 9/25/07, Tim McConnell <[EMAIL PROTECTED]> wrote:
> >
> > Hi Erik, Jason and Viet, Today I've updated the "Apache Geronimo
> > Development
> > Tools Subproject" website (below) to include the latest information
> > about the
> > new release of the Geronimo Eclipse Plugin.
> >
> > ---> http://geronimo.apache.org/development-tools.html
>
>
>
> Excellent.  I'll take a look and let you know if there are any issues.
>
> I've also included some information about the J2G Migration tool from some
> > of
> > the notes in this thread. Since I don't know a lot about this new tool,
> > I'm
> > hoping you all might review what I have thus far to see if it's kinda
> > what you
> > all had envisioned. Also, every Sunday I push out the latest trunk build
> > of the
> > Geronimo Eclipse plugin to our unstable site (below). I've assumed it's
> > okay to
> > do the same for the J2G plugin as well and have listed it in the
> > downloads
> > sections.
> >
> > ---> http://people.apache.org/dist/geronimo/eclipse/unstable/
>
>
>
> That's not just okay, it's fantastic.   Thanks for doing that.
>
> Regards,
>
> Jason Warner
>
> Thanks
> >
> >
> > Erik B. Craig wrote:
> > > All,
> > >
> > > After the recent round of changes and improvements around j2g (usable
> > > from within the Eclipse IDE UI, Annotations support, improved
> > > logging/information output, support for EJB 3), as well as a bit of
> > > interest out in the general open source community in moving
> > applications
> > > from Jboss to Geronimo (such as today's inquiry on theserverside.com
> > > < http://theserverside.com>), I feel as though it would be of some
> > > benefit to have j2g, at least the content in our confluence wiki (
> > > http://cwiki.apache.org/GMOxDOC20/j2g-migration-tool.html) linked
> > > somewhere on the actual geronimo homepage. I was thinking either as
> > it's
> > > own link under 'Subprojects', much as Development Tools, GBuild, or
> > > XBean are situated, or as an addition inside the Development Tools
> > page,
> > > much as the current Eclipse Plug-in section rests within there.
> > >
> > > I am willing to commit to doing a bit of additional writing (beyond
> > what
> > > is on the wiki) if it were to be under it's own section, or a
> > subsection
> > > of development tools if necessary, but I think it would be good to get
> > > it up and out there sooner rather than later, especially to coincide
> > > with the recent release of 2.0.1 to perhaps show those out there
> > > remotely interested in migrating, there are tools available to assist
> > > and perhaps 'hold their hand' a bit.
> > >
> > >
> > > Thoughts? Comments? Objections?
> > >
> > > Thanks
> > > --
> > > Erik B. Craig
> >
> > --
> > Thanks,
> > Tim McConnell
> >
>
>

Re: [BUILD] Trunk: Successful

[Prasad Kashyap]

This is weird. The maven-maven-plugin aborts when it encounters an
error on Linux. On Windows, it keeps going.

Cheers
Prasad

On 9/25/07, Jarek Gawor <[EMAIL PROTECTED]> wrote:
> Oh, nice. Is there a way to configure maven not to abort the tests in such 
> case?
>
> Jarek
>
> On 9/25/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> > http://people.apache.org/~prasad/binaries/trunk/20070925/test-1600.log
> >
> > We have to exclude the ejbcontainer tests.
> >
> > Cheers
> > Prasad.
> >
> >
> > On 9/25/07, Jarek Gawor <[EMAIL PROTECTED]> wrote:
> > > Prasad,
> > >
> > > Do you know why the ResultsSummary page only shows a subset of the
> > > results for 2.1? For example, the results for web-testsuite are
> > > missing.
> > >
> > > Jarek
> > >
> > > On 25 Sep 2007 21:09:21 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 
> > > wrote:
> > > > OpenEJB trunk at 579286
> > > > Geronimo Revision: 579360 built with tests included
> > > >
> > > > See the full build-1600.log file at 
> > > > http://people.apache.org/~prasad/binaries/trunk/20070925/build-1600.log
> > > > Download the binaries from 
> > > > http://people.apache.org/~prasad/binaries/trunk/20070925
> > > >
> > > > [INFO] BUILD SUCCESSFUL
> > > > [INFO] 
> > > > 
> > > > [INFO] Total time: 28 minutes 55 seconds
> > > > [INFO] Finished at: Tue Sep 25 16:40:36 EDT 2007
> > > > [INFO] Final Memory: 211M/1010M
> > > > [INFO] 
> > > > 
> > > >
> > > > TESTSUITE RESULTS (Failures only)
> > > > =
> > > > See detailed results at 
> > > > http://people.apache.org/~prasad/testsuite/ResultsSummary.html
> > > >
> > > > [INFO] Running console-testsuite.advance-test
> > > > [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> > > > 141.882 sec <<< FAILURE!
> > > > --
> > > > [INFO] Running deployment-testsuite.jca-cms
> > > > [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> > > > 0.313 sec <<< FAILURE!
> > > > --
> > > > [INFO] Running sec-testsuite.security
> > > > [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 
> > > > 0.638 sec <<< FAILURE!
> > > >
> > > >
> > >
> >
>

[jira] Created: (GERONIMODEVTOOLS-222) Warning messages at Eclipse Plugin startup

[Tim McConnell (JIRA)]

Warning messages at Eclipse Plugin startup
--

 Key: GERONIMODEVTOOLS-222
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-222
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.0.0
Reporter: Tim McConnell
Assignee: Tim McConnell
Priority: Minor
 Fix For: 2.0.1


These warning messages should be eliminated at Eclipse plugin startup. They are 
located in \workspaces\.metadata\.log file. 

!ENTRY org.eclipse.emf.ecore 2 0 2007-09-21 17:37:42.265
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'deployment'

!ENTRY org.eclipse.emf.ecore 2 0 2007-09-21 17:37:42.281
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'naming'

!ENTRY org.eclipse.emf.ecore 2 0 2007-09-21 17:37:42.281
!MESSAGE Both 'org.apache.geronimo.deployment.model' and 
'org.apache.geronimo.v11.deployment.model' register an extension parser for 
'web'


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

[jira] Updated: (GERONIMO-3456) Make MEJB security configurable

[Anita Kulshreshtha (JIRA)]

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

Anita Kulshreshtha updated GERONIMO-3456:
-

Attachment: GERONIMO-3456.patch

GERONIMO-3456 is the latest patch

> Make MEJB security configurable
> ---
>
> Key: GERONIMO-3456
> URL: https://issues.apache.org/jira/browse/GERONIMO-3456
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB, security
>Affects Versions: 2.0.1, 2.1
> Environment: All
>Reporter: Anita Kulshreshtha
>Assignee: Anita Kulshreshtha
>Priority: Critical
> Fix For: 2.0.2, 2.1
>
> Attachments: configs.diff, configs.patch, configs.patch, 
> GERONIMO-3456.patch, mejb-ear-2.1-SNAPSHOT.ear, mejb-ejb-2.1-SNAPSHOT.jar, 
> mejb-war-2.1-SNAPSHOT.war, mejb.diff, MEJB.java, mejb.patch
>
>
> Currently access to MEJB is not controlled. Add configurable security for 
> MEJB.

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

Re: Adding j2g to site

[Jason Warner]

On 9/25/07, Tim McConnell <[EMAIL PROTECTED]> wrote:
>
> Hi Erik, Jason and Viet, Today I've updated the "Apache Geronimo
> Development
> Tools Subproject" website (below) to include the latest information about
> the
> new release of the Geronimo Eclipse Plugin.
>
> ---> http://geronimo.apache.org/development-tools.html



Excellent.  I'll take a look and let you know if there are any issues.

I've also included some information about the J2G Migration tool from some
> of
> the notes in this thread. Since I don't know a lot about this new tool,
> I'm
> hoping you all might review what I have thus far to see if it's kinda what
> you
> all had envisioned. Also, every Sunday I push out the latest trunk build
> of the
> Geronimo Eclipse plugin to our unstable site (below). I've assumed it's
> okay to
> do the same for the J2G plugin as well and have listed it in the downloads
> sections.
>
> ---> http://people.apache.org/dist/geronimo/eclipse/unstable/



That's not just okay, it's fantastic.   Thanks for doing that.

Regards,

Jason Warner

Thanks
>
>
> Erik B. Craig wrote:
> > All,
> >
> > After the recent round of changes and improvements around j2g (usable
> > from within the Eclipse IDE UI, Annotations support, improved
> > logging/information output, support for EJB 3), as well as a bit of
> > interest out in the general open source community in moving applications
> > from Jboss to Geronimo (such as today's inquiry on theserverside.com
> > ), I feel as though it would be of some
> > benefit to have j2g, at least the content in our confluence wiki (
> > http://cwiki.apache.org/GMOxDOC20/j2g-migration-tool.html) linked
> > somewhere on the actual geronimo homepage. I was thinking either as it's
> > own link under 'Subprojects', much as Development Tools, GBuild, or
> > XBean are situated, or as an addition inside the Development Tools page,
> > much as the current Eclipse Plug-in section rests within there.
> >
> > I am willing to commit to doing a bit of additional writing (beyond what
> > is on the wiki) if it were to be under it's own section, or a subsection
> > of development tools if necessary, but I think it would be good to get
> > it up and out there sooner rather than later, especially to coincide
> > with the recent release of 2.0.1 to perhaps show those out there
> > remotely interested in migrating, there are tools available to assist
> > and perhaps 'hold their hand' a bit.
> >
> >
> > Thoughts? Comments? Objections?
> >
> > Thanks
> > --
> > Erik B. Craig
>
> --
> Thanks,
> Tim McConnell
>

Re: Adding j2g to site

[Tim McConnell]

Hi Erik, Jason and Viet, Today I've updated the "Apache Geronimo Development 
Tools Subproject" website (below) to include the latest information about the 
new release of the Geronimo Eclipse Plugin.


---> http://geronimo.apache.org/development-tools.html

I've also included some information about the J2G Migration tool from some of 
the notes in this thread. Since I don't know a lot about this new tool, I'm 
hoping you all might review what I have thus far to see if it's kinda what you 
all had envisioned. Also, every Sunday I push out the latest trunk build of the 
Geronimo Eclipse plugin to our unstable site (below). I've assumed it's okay to 
do the same for the J2G plugin as well and have listed it in the downloads 
sections.


---> http://people.apache.org/dist/geronimo/eclipse/unstable/

Thanks


Erik B. Craig wrote:

All,

After the recent round of changes and improvements around j2g (usable 
from within the Eclipse IDE UI, Annotations support, improved 
logging/information output, support for EJB 3), as well as a bit of 
interest out in the general open source community in moving applications 
from Jboss to Geronimo (such as today's inquiry on theserverside.com 
), I feel as though it would be of some 
benefit to have j2g, at least the content in our confluence wiki ( 
http://cwiki.apache.org/GMOxDOC20/j2g-migration-tool.html) linked 
somewhere on the actual geronimo homepage. I was thinking either as it's 
own link under 'Subprojects', much as Development Tools, GBuild, or 
XBean are situated, or as an addition inside the Development Tools page, 
much as the current Eclipse Plug-in section rests within there.


I am willing to commit to doing a bit of additional writing (beyond what 
is on the wiki) if it were to be under it's own section, or a subsection 
of development tools if necessary, but I think it would be good to get 
it up and out there sooner rather than later, especially to coincide 
with the recent release of 2.0.1 to perhaps show those out there 
remotely interested in migrating, there are tools available to assist 
and perhaps 'hold their hand' a bit.



Thoughts? Comments? Objections?

Thanks
--
Erik B. Craig


--
Thanks,
Tim McConnell

Re: [BUILD] Trunk: Successful

[Jarek Gawor]

Oh, nice. Is there a way to configure maven not to abort the tests in such case?

Jarek

On 9/25/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> http://people.apache.org/~prasad/binaries/trunk/20070925/test-1600.log
>
> We have to exclude the ejbcontainer tests.
>
> Cheers
> Prasad.
>
>
> On 9/25/07, Jarek Gawor <[EMAIL PROTECTED]> wrote:
> > Prasad,
> >
> > Do you know why the ResultsSummary page only shows a subset of the
> > results for 2.1? For example, the results for web-testsuite are
> > missing.
> >
> > Jarek
> >
> > On 25 Sep 2007 21:09:21 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > OpenEJB trunk at 579286
> > > Geronimo Revision: 579360 built with tests included
> > >
> > > See the full build-1600.log file at 
> > > http://people.apache.org/~prasad/binaries/trunk/20070925/build-1600.log
> > > Download the binaries from 
> > > http://people.apache.org/~prasad/binaries/trunk/20070925
> > >
> > > [INFO] BUILD SUCCESSFUL
> > > [INFO] 
> > > 
> > > [INFO] Total time: 28 minutes 55 seconds
> > > [INFO] Finished at: Tue Sep 25 16:40:36 EDT 2007
> > > [INFO] Final Memory: 211M/1010M
> > > [INFO] 
> > > 
> > >
> > > TESTSUITE RESULTS (Failures only)
> > > =
> > > See detailed results at 
> > > http://people.apache.org/~prasad/testsuite/ResultsSummary.html
> > >
> > > [INFO] Running console-testsuite.advance-test
> > > [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> > > 141.882 sec <<< FAILURE!
> > > --
> > > [INFO] Running deployment-testsuite.jca-cms
> > > [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> > > 0.313 sec <<< FAILURE!
> > > --
> > > [INFO] Running sec-testsuite.security
> > > [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 
> > > 0.638 sec <<< FAILURE!
> > >
> > >
> >
>

Re: [BUILD] Trunk: Successful

[Prasad Kashyap]

http://people.apache.org/~prasad/binaries/trunk/20070925/test-1600.log

We have to exclude the ejbcontainer tests.

Cheers
Prasad.


On 9/25/07, Jarek Gawor <[EMAIL PROTECTED]> wrote:
> Prasad,
>
> Do you know why the ResultsSummary page only shows a subset of the
> results for 2.1? For example, the results for web-testsuite are
> missing.
>
> Jarek
>
> On 25 Sep 2007 21:09:21 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > OpenEJB trunk at 579286
> > Geronimo Revision: 579360 built with tests included
> >
> > See the full build-1600.log file at 
> > http://people.apache.org/~prasad/binaries/trunk/20070925/build-1600.log
> > Download the binaries from 
> > http://people.apache.org/~prasad/binaries/trunk/20070925
> >
> > [INFO] BUILD SUCCESSFUL
> > [INFO] 
> > 
> > [INFO] Total time: 28 minutes 55 seconds
> > [INFO] Finished at: Tue Sep 25 16:40:36 EDT 2007
> > [INFO] Final Memory: 211M/1010M
> > [INFO] 
> > 
> >
> > TESTSUITE RESULTS (Failures only)
> > =
> > See detailed results at 
> > http://people.apache.org/~prasad/testsuite/ResultsSummary.html
> >
> > [INFO] Running console-testsuite.advance-test
> > [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> > 141.882 sec <<< FAILURE!
> > --
> > [INFO] Running deployment-testsuite.jca-cms
> > [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> > 0.313 sec <<< FAILURE!
> > --
> > [INFO] Running sec-testsuite.security
> > [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 
> > 0.638 sec <<< FAILURE!
> >
> >
>

Re: [BUILD] Trunk: Successful

[Jarek Gawor]

Prasad,

Do you know why the ResultsSummary page only shows a subset of the
results for 2.1? For example, the results for web-testsuite are
missing.

Jarek

On 25 Sep 2007 21:09:21 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> OpenEJB trunk at 579286
> Geronimo Revision: 579360 built with tests included
>
> See the full build-1600.log file at 
> http://people.apache.org/~prasad/binaries/trunk/20070925/build-1600.log
> Download the binaries from 
> http://people.apache.org/~prasad/binaries/trunk/20070925
>
> [INFO] BUILD SUCCESSFUL
> [INFO] 
> 
> [INFO] Total time: 28 minutes 55 seconds
> [INFO] Finished at: Tue Sep 25 16:40:36 EDT 2007
> [INFO] Final Memory: 211M/1010M
> [INFO] 
> 
>
> TESTSUITE RESULTS (Failures only)
> =
> See detailed results at 
> http://people.apache.org/~prasad/testsuite/ResultsSummary.html
>
> [INFO] Running console-testsuite.advance-test
> [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
> 141.882 sec <<< FAILURE!
> --
> [INFO] Running deployment-testsuite.jca-cms
> [INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.313 
> sec <<< FAILURE!
> --
> [INFO] Running sec-testsuite.security
> [INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.638 
> sec <<< FAILURE!
>
>

Re: [DISCUSS] G 2.0.2 Release plan

[David Blevins]

On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:

One thing I've noticed -- the default JNDI name for EJB's has been  
changed in OpenEJB. So, there is a compatibility issue with 2.0.1.  
We might be able to configure how OpenEJB generates this default to  
maintain backward compatibility. Better, IMO, to go ahead and match  
OpenEJB's behavior.


There are no compatibility issues as it was explicitly set in  
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/ 
{interfaceClass}  (actually it's {deploymentId}/{interfaceClass} and  
deploymentId will be {moduleId}/{ejbName}).  It'll still be the same  
in Geronimo 2.0.2, just now it can be changed to something shorter.


I'd be fine with Geronimo using the OpenEJB default of essentially  
{ejbName}{interfaceType.annotationName} (it's {deploymentId} 
{interfaceType.annotation} where deploymentId defaults to {ejbName}),  
but it's definitely a default that targets people with just a couple  
apps.  People in bigger environments would have to set the jndiname  
and deploymentId formats to something less likely to conflict.


-David

Re: J2G build problem

[Erik B. Craig]

Ted,

I just checked out the j2g trunk myself, and I am getting the same errors
you mentioned.
I am going to attempt to play with it a bit to see if I can't figure out the
cause, however if you beat me to it, let me know what you found


On 9/25/07, Ted Kirby <[EMAIL PROTECTED]> wrote:
>
> From trunk, rev 578938, with a clean build tree and repo, I get:
>
> [INFO] Compiling 20 source files to
> D:\gdvtls\j2g\trunk\plugins\org.apache.geron
> imo.j2g.sources\target\classes
> [INFO]
> 
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] Compilation failure
>
>
> D:\gdvtls\j2g\trunk\plugins\org.apache.geronimo.j2g.sources\src\org\apache\geron
> imo\j2g\sources\environment\AbsoluteNameSolver.java:[227,120] cannot find
> symbol
>
> symbol  : method getLineNumber(int)
> location: class org.eclipse.jdt.core.dom.CompilationUnit
>
> I get about 20 of those errors.
>
> Does anyone have any suggestions?
>
> Thanks,
>
> Ted Kirby
>



-- 
Erik B. Craig

Re: XML Schemas

[Aaron Mulder]

On 9/25/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> The idea is to ease development from IDE's that will pick up the schemas 
> right away. Not sure the redirect would work for these scenarios.

Well, let me give a specific example.  Let's say you have a web app's web.xml:


http://java.sun.com/xml/ns/j2ee";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
 version="2.4">
...


The namespace is "http://java.sun.com/xml/ns/j2ee"; and the schema URL
is "http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; -- they are
different.  However, if you declare them like that in the web.xml
header, any IDE ought to be able to find the schema based on the
xsi:schemaLocation attribute.  So it's not strictly necessary to make
the path on the web site match the namespace to get your IDE to work.

Thanks,
  Aaron

> I tried the aliases, just a couple of symbolic links, but then realized about 
> the different directories for the schemas so I was hoping there would be 
> another way (maybe a maven plugin) that would to the job.  Apparently there 
> isn't.
>
> I guess I'll get back to the alias work for now until we figure out a better 
> way to do this.
>
> Cheers!
> Hernan
>
> Aaron Mulder wrote:
> > I'm not that big a fan of trying to make the schema namespace be an
> > actual working URL.  Should the schema's namespace end in ".xsd"?
> > That seems weird.  Plus we have no control over the location for many
> > of the schemas we use (other projects we use, the Sun schemas, etc.)
> > And it might result in us scattering our schemas across several
> > directories on the site, which over several releases could get quite
> > messy.
> >
> > In contrast, we can point to the correct URL in e.g. a comment at the
> > top of the schema, and any file using that schema can include an
> > attribute pointing to the specific URL for the schema.  But I guess I
> > don't feel super-strongly, other than that I think the main navigation
> > for the site ought to always let you get to a listing of the pertinent
> > schemas.
> >
> > Another possibility would be to just set up aliases or redirects so we
> > can file the schemas where we want and then make the namespace URLs
> > forward or redirect to the actual schema files for additional
> > convenience.
> >
> > Thanks,
> >Aaron
> >
> > On 9/25/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> >> Hi All,
> >> trying to deal with the schemas update on the web site and I'm looking to 
> >> some things I would like to get your input.
> >>
> >> First of all the actual schemas file name don't match the target name 
> >> space defined in the schema itself.
> >>
> >> Here is the associated JIRA ( 
> >> https://issues.apache.org/jira/browse/GERONIMO-3425 ). This is mainly for 
> >> updating the web site but I think it would be more clear for everybody to 
> >> have matching names anyway.
> >>
> >> Is it feasible/practical to have the schemas file names match the name 
> >> space?
> >>
> >> Second, in order to have the schemas available on a target's name space 
> >> matching URL (http://geronimo.apache.org/xml/ns ...) we need to have and 
> >> maintain up-to-date copy a the schemas on the web site trunk.
> >>
> >> We currently have the schemas scattered all over the server trunk. Last 
> >> time Jarek manually copied the files over but clearly this can not be a 
> >> manual task.
> >>
> >> Anybody has any ideas for having this automatically updated?
> >>
> >> Cheers!
> >> Hernan
> >>
> >>
> >
>
>

[jira] Updated: (GERONIMO-3441) Server monitoring and management

[Viet Hung Nguyen (JIRA)]

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

Viet Hung Nguyen updated GERONIMO-3441:
---

Attachment: (was: MRC.zip)

> Server monitoring and management
> 
>
> Key: GERONIMO-3441
> URL: https://issues.apache.org/jira/browse/GERONIMO-3441
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: general
>Affects Versions: 2.1
> Environment: All
>Reporter: Erik B. Craig
>Assignee: Erik B. Craig
> Attachments: MRC-server.zip, screenshot1.jpg, screenshot2.jpg, 
> stats.patch, statsportlet.zip
>
>
> Currently, there is not a good way of surfacing Geronimo's server information 
> so that an administrator can monitor the server's status. The architecture of 
> using MBeans is established, but not fully exploited. This enhancement will 
> take advantage of what Geronimo currently offers and extend it so that a 
> server can tap into a cluster of servers and extract information from 
> specific Geronimo servers or even aggregates of Geronimo servers.
> The goal is to have one machine be able to reach out to all Geronimo servers 
> in order to fetch data or even alter their state. This will be especially 
> useful in the case of someone having to monitor a large number of Geronimo 
> servers.
> Viet Nguyen and myself have completed a bit of framework towards this goal, 
> to be attached to this jira
> In-depth information can be found in the confluence wiki here
> http://cwiki.apache.org/confluence/display/GMOxDEV/Monitoring+and+Management+Service

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

J2G build problem

[Ted Kirby]

>From trunk, rev 578938, with a clean build tree and repo, I get:

[INFO] Compiling 20 source files to D:\gdvtls\j2g\trunk\plugins\org.apache.geron
imo.j2g.sources\target\classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

D:\gdvtls\j2g\trunk\plugins\org.apache.geronimo.j2g.sources\src\org\apache\geron
imo\j2g\sources\environment\AbsoluteNameSolver.java:[227,120] cannot find symbol

symbol  : method getLineNumber(int)
location: class org.eclipse.jdt.core.dom.CompilationUnit

I get about 20 of those errors.

Does anyone have any suggestions?

Thanks,

Ted Kirby

[jira] Updated: (GERONIMO-3441) Server monitoring and management

[Viet Hung Nguyen (JIRA)]

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

Viet Hung Nguyen updated GERONIMO-3441:
---

Attachment: stats.patch
MRC-server.zip

Erik and I have made a lot of changes to our initial approach. We are now 
dealing exclusively with JSR 77 stats. The attached patch, will surface Jetty 
Container stats so that the collecting agent (which is in MRC-server.zip) can 
collect both tomcat or jetty stats. So far, this collecting agent will work on 
any container and, by default, will choose to collect and save an ongoing 
history of Container and Connector stats (if they are provided). There is also 
the added feature of allowing the client (in this case, an Admin) to add/remove 
other JSR-77 stats from a list of available mbeans.

> Server monitoring and management
> 
>
> Key: GERONIMO-3441
> URL: https://issues.apache.org/jira/browse/GERONIMO-3441
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: general
>Affects Versions: 2.1
> Environment: All
>Reporter: Erik B. Craig
>Assignee: Erik B. Craig
> Attachments: MRC-server.zip, MRC.zip, screenshot1.jpg, 
> screenshot2.jpg, stats.patch, statsportlet.zip
>
>
> Currently, there is not a good way of surfacing Geronimo's server information 
> so that an administrator can monitor the server's status. The architecture of 
> using MBeans is established, but not fully exploited. This enhancement will 
> take advantage of what Geronimo currently offers and extend it so that a 
> server can tap into a cluster of servers and extract information from 
> specific Geronimo servers or even aggregates of Geronimo servers.
> The goal is to have one machine be able to reach out to all Geronimo servers 
> in order to fetch data or even alter their state. This will be especially 
> useful in the case of someone having to monitor a large number of Geronimo 
> servers.
> Viet Nguyen and myself have completed a bit of framework towards this goal, 
> to be attached to this jira
> In-depth information can be found in the confluence wiki here
> http://cwiki.apache.org/confluence/display/GMOxDEV/Monitoring+and+Management+Service

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

Re: XML Schemas

[Hernan Cunico]

The idea is to ease development from IDE's that will pick up the schemas right 
away. Not sure the redirect would work for these scenarios.

I tried the aliases, just a couple of symbolic links, but then realized about 
the different directories for the schemas so I was hoping there would be 
another way (maybe a maven plugin) that would to the job.  Apparently there 
isn't.

I guess I'll get back to the alias work for now until we figure out a better 
way to do this.

Cheers!
Hernan

Aaron Mulder wrote:

I'm not that big a fan of trying to make the schema namespace be an
actual working URL.  Should the schema's namespace end in ".xsd"?
That seems weird.  Plus we have no control over the location for many
of the schemas we use (other projects we use, the Sun schemas, etc.)
And it might result in us scattering our schemas across several
directories on the site, which over several releases could get quite
messy.

In contrast, we can point to the correct URL in e.g. a comment at the
top of the schema, and any file using that schema can include an
attribute pointing to the specific URL for the schema.  But I guess I
don't feel super-strongly, other than that I think the main navigation
for the site ought to always let you get to a listing of the pertinent
schemas.

Another possibility would be to just set up aliases or redirects so we
can file the schemas where we want and then make the namespace URLs
forward or redirect to the actual schema files for additional
convenience.

Thanks,
   Aaron

On 9/25/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:

Hi All,
trying to deal with the schemas update on the web site and I'm looking to some 
things I would like to get your input.

First of all the actual schemas file name don't match the target name space 
defined in the schema itself.

Here is the associated JIRA ( 
https://issues.apache.org/jira/browse/GERONIMO-3425 ). This is mainly for 
updating the web site but I think it would be more clear for everybody to have 
matching names anyway.

Is it feasible/practical to have the schemas file names match the name space?

Second, in order to have the schemas available on a target's name space 
matching URL (http://geronimo.apache.org/xml/ns ...) we need to have and 
maintain up-to-date copy a the schemas on the web site trunk.

We currently have the schemas scattered all over the server trunk. Last time 
Jarek manually copied the files over but clearly this can not be a manual task.

Anybody has any ideas for having this automatically updated?

Cheers!
Hernan

[jira] Commented: (GERONIMO-3423) Ensure that users can change the ejb jndi name format

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy commented on GERONIMO-3423:
---

I guess it is Rev 570242.

> Ensure that users can change the ejb jndi name format
> -
>
> Key: GERONIMO-3423
> URL: https://issues.apache.org/jira/browse/GERONIMO-3423
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0, 2.0.x
>Reporter: David Blevins
>Assignee: David Blevins
> Fix For: 2.0.x, 2.1
>
>
> Right now OpenEjbSystemGBean is hard coded to always set a value for 
> "openejb.jndiname.format".  We should check to see if it's set first and if 
> so, not reset it.  We should log a warning message if it's changed that 
> javaee app client's will not work.

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

Re: [DISCUSS] G 2.0.2 Release plan

[Vamsavardhana Reddy]

I guess it is rev 570242 in trunk.

Vamsi

On 9/26/07, Donald Woods <[EMAIL PROTECTED]> wrote:
>
> OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA
> emails.)
>
> The only one I couldn't figure out, was:
> https://issues.apache.org/jira/browse/GERONIMO-3423
>
>
> -Donald
>
> Donald Woods wrote:
> > BTW - I'm going through JIRA today and updating any Fix For: 2.0.x
> > closed/resolved issues to use the correct release attribute, so we can
> > generate a valid list of fixes for the 2.0.2 release notes
> >
> > -Donald
> >
> > Kevan Miller wrote:
> >> All,
> >> I think it's time to start rolling out a 2.0.2 release. There have
> >> been a number of fixes in response to user issues, since 2.0.1. Time,
> >> I think, to make these available in a release. We'd also be able to
> >> make use of released versions of OpenJPA, Axis2, and hopefully
> >> OpenEjb, whittling away at our local builds...
> >>
> >> I think we have one must-fix problem that is outstanding -- the MEJB
> >> security issue. Assuming we resolve this problem, are there any other
> >> issues which must be resolved prior to a 2.0.2 release?
> >>
> >> Assuming we're in general agreement, I'd set a goal of creating a
> >> release candidate by next Friday (Sept 21). I'm volunteering to be the
> >> release manager.
> >>
> >> Thoughts?
> >>
> >> --kevan
> >>
> >>
>
>

Re: Geronimo box on Download page still says 1.1

[Vamsavardhana Reddy]

Hernan,

I see some 2.0 box images at
https://svn.apache.org/repos/asf/geronimo/site/trunk/art and they have been
there since end of March!!  Can you update the downloads page to show a 2.0box?

Vamsi

On 8/22/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>
> I've been trying for ages to get these updated. I asked folks from other
> projects using similar boxes but couldn't figure out what software they were
> using.
>
> All I have is the Photoshop suit but I'm sure those were created with
> something else.
>
> Cheers!
> Hernan
>
> Matt Hogstrom wrote:
> > Does anyone know how to get an updated box for Geronimo that says
> > 2.0.1?  Since its the first thing people see on that page seems like it
> > would make more sense for the release number to be the most recent.  I'm
> > happy to do it but not sure what software was used.
> >
>

Re: [DISCUSS] G 2.0.2 Release plan

[Donald Woods]

OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA emails.)

The only one I couldn't figure out, was:
https://issues.apache.org/jira/browse/GERONIMO-3423


-Donald

Donald Woods wrote:
BTW - I'm going through JIRA today and updating any Fix For: 2.0.x 
closed/resolved issues to use the correct release attribute, so we can 
generate a valid list of fixes for the 2.0.2 release notes


-Donald

Kevan Miller wrote:

All,
I think it's time to start rolling out a 2.0.2 release. There have 
been a number of fixes in response to user issues, since 2.0.1. Time, 
I think, to make these available in a release. We'd also be able to 
make use of released versions of OpenJPA, Axis2, and hopefully 
OpenEjb, whittling away at our local builds...


I think we have one must-fix problem that is outstanding -- the MEJB 
security issue. Assuming we resolve this problem, are there any other 
issues which must be resolved prior to a 2.0.2 release?


Assuming we're in general agreement, I'd set a goal of creating a 
release candidate by next Friday (Sept 21). I'm volunteering to be the 
release manager.


Thoughts?

--kevan




smime.p7s
Description: S/MIME Cryptographic Signature

Re: XML Schemas

[Donald Woods]

I was being smart a$$... :-)
It doesn't handle schemas today, nor does maven-deploy-plugin

-Donald

Hernan Cunico wrote:
would this plugin be smart enough to place/rename the schemas in the 
right "directory" accordingly to what's specified as the target name space?


Cheers!
Hernan

Donald Woods wrote:

Nope, but sounds like a good job for the maven-release-plugin :-)


-Donald

Hernan Cunico wrote:

Hi All,
trying to deal with the schemas update on the web site and I'm 
looking to some things I would like to get your input.


First of all the actual schemas file name don't match the target name 
space defined in the schema itself.


Here is the associated JIRA ( 
https://issues.apache.org/jira/browse/GERONIMO-3425 ). This is mainly 
for updating the web site but I think it would be more clear for 
everybody to have matching names anyway.
Is it feasible/practical to have the schemas file names match the 
name space?


Second, in order to have the schemas available on a target's name 
space matching URL (http://geronimo.apache.org/xml/ns ...) we need to 
have and maintain up-to-date copy a the schemas on the web site trunk.


We currently have the schemas scattered all over the server trunk. 
Last time Jarek manually copied the files over but clearly this can 
not be a manual task.


Anybody has any ideas for having this automatically updated?

Cheers!
Hernan







smime.p7s
Description: S/MIME Cryptographic Signature

Re: XML Schemas

[Aaron Mulder]

I'm not that big a fan of trying to make the schema namespace be an
actual working URL.  Should the schema's namespace end in ".xsd"?
That seems weird.  Plus we have no control over the location for many
of the schemas we use (other projects we use, the Sun schemas, etc.)
And it might result in us scattering our schemas across several
directories on the site, which over several releases could get quite
messy.

In contrast, we can point to the correct URL in e.g. a comment at the
top of the schema, and any file using that schema can include an
attribute pointing to the specific URL for the schema.  But I guess I
don't feel super-strongly, other than that I think the main navigation
for the site ought to always let you get to a listing of the pertinent
schemas.

Another possibility would be to just set up aliases or redirects so we
can file the schemas where we want and then make the namespace URLs
forward or redirect to the actual schema files for additional
convenience.

Thanks,
   Aaron

On 9/25/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
> Hi All,
> trying to deal with the schemas update on the web site and I'm looking to 
> some things I would like to get your input.
>
> First of all the actual schemas file name don't match the target name space 
> defined in the schema itself.
>
> Here is the associated JIRA ( 
> https://issues.apache.org/jira/browse/GERONIMO-3425 ). This is mainly for 
> updating the web site but I think it would be more clear for everybody to 
> have matching names anyway.
>
> Is it feasible/practical to have the schemas file names match the name space?
>
> Second, in order to have the schemas available on a target's name space 
> matching URL (http://geronimo.apache.org/xml/ns ...) we need to have and 
> maintain up-to-date copy a the schemas on the web site trunk.
>
> We currently have the schemas scattered all over the server trunk. Last time 
> Jarek manually copied the files over but clearly this can not be a manual 
> task.
>
> Anybody has any ideas for having this automatically updated?
>
> Cheers!
> Hernan
>
>

[jira] Updated: (GERONIMO-3471) Enabling Web Server Manager statistics appears to have no effect in admin console

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3471:
---

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

updated Fixed For field

> Enabling Web Server Manager statistics appears to have no effect in admin 
> console 
> --
>
> Key: GERONIMO-3471
> URL: https://issues.apache.org/jira/browse/GERONIMO-3471
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0.1
>Reporter: Kevan Miller
>Priority: Minor
>
> Aleksandr reports that clicking "enable" statistics on the Web Server page of 
> the admin console has no effect. I tested on a Jetty server and it indeed 
> does not work (or has no visible impact). 

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

[jira] Updated: (GERONIMO-3412) Upgrade geronimo.components to released 2.0.1 levels

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3412:
---

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

updated Fixed For field

> Upgrade geronimo.components to released 2.0.1 levels
> 
>
> Key: GERONIMO-3412
> URL: https://issues.apache.org/jira/browse/GERONIMO-3412
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 2.0.x, 2.1
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.0.2, 2.1
>
>
> The geronimo.components files have finally made it to 
> http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/geronimo/components/

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

[jira] Updated: (GERONIMO-3248) Extraneous WARN messages during deployment of resource-env-refs in EJB jar

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3248:
---

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

updated Fixed For field

> Extraneous WARN messages during deployment of resource-env-refs in EJB jar
> --
>
> Key: GERONIMO-3248
> URL: https://issues.apache.org/jira/browse/GERONIMO-3248
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M6
> Environment: Windows XP SP2
>Reporter: Aman Nanner
>Assignee: Vamsavardhana Reddy
>Priority: Minor
> Fix For: 2.0.2, 2.1
>
> Attachments: GERONIMO-3248-new.patch
>
>
> During deployment of one of my EJB jar files in my EAR, I get the following 
> WARN messages:
> {code}
> 14:29:37,425 WARN  [AdminObjectRefBuilder] Failed to build reference to Admin 
> object reference [jms/UnsequencedDestination, jms/MailQueue, 
> jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue, 
> jms/SequencedDestination, jms/InboundIntegrationQueue, 
> jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in 
> deployment descriptor missing.
> 14:29:37,440 WARN  [ResourceRefBuilder] Failed to build reference to resource 
> reference [jms/ConnectionFactory, jms/QueueConnectionFactory, 
> mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason - 
> corresponding entry in deployment descriptor missing.
> {code}
> This occurs at the point in the following point in the stack:
> {code}
> AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
> {code}
> The "specDD" that is passed in is a XML fragment for a specific session bean. 
>  However, the "plan" that is passed in contains all the resource-ref and 
> resource-env-ref elements in the openejb-jar.xml plan.  Therefore, the 
> "refMap" variable does not get completely emptied out, since the specific 
> session bean will only contain a subset of the resource-env-refs that are 
> defined in the plan.

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

[jira] Updated: (GERONIMO-3310) Geronimo is not finding message-destination elements in ejb-jar.xmls

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3310:
---

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

updated Fixed For field

> Geronimo is not finding message-destination elements in ejb-jar.xmls
> 
>
> Key: GERONIMO-3310
> URL: https://issues.apache.org/jira/browse/GERONIMO-3310
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.2, 2.1
>
>
> daytrader has a couple message-destination elements in the ejb-jar.xml.  They 
> aren't getting picked up by the time AdminObjectRefBuilder needs to see them.
> I think in g. 1.x we had some hackery whereby the openejb deployer was 
> calling naming builders initContext with the entire ejb-jar.xml, and then 
> buildNaming for each ejb.  Not sure what we want to do yet.

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

[jira] Updated: (GERONIMO-3409) Several geronimo-web.xml files still use a 2.0-SNAPSHOT depend. Upgrade to geronimo.components vers=2.0.1

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3409:
---

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

updated Fixed For field

> Several geronimo-web.xml files still use a 2.0-SNAPSHOT depend.  Upgrade to 
> geronimo.components vers=2.0.1
> --
>
> Key: GERONIMO-3409
> URL: https://issues.apache.org/jira/browse/GERONIMO-3409
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 2.0, 2.0.x, 2.1
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.0.1, 2.0.2, 2.1
>
>
> Several geronimo-web.xml files still use a 2.0-SNAPSHOT depend.
> One testsuite file has a hard-coded depend on a 2.0 module.
> Need to upgrade to geronimo.components vers=2.0.1, which is hard-coded to 2.0 
> in configs\client-transaction\pom.xml

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

[jira] Updated: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3348:
---

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

updated Fixed For field

> java.lang.NoSuchMethodError in 
> org.springframework.context.i18n.LocaleContextHolder
> ---
>
> Key: GERONIMO-3348
> URL: https://issues.apache.org/jira/browse/GERONIMO-3348
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M6
> Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 
> Pentium III (Katmai) GenuineIntel GNU/Linux
> JDK-1.5.0.12
>Reporter: Aleksandr Tarutin
>Assignee: Kevan Miller
> Fix For: 2.0.2, 2.1
>
>
> When deploying and running [Proximity|http://proximity.abstracthorizon.org/] 
> it works without any problem in geronimo-1.1.1. But when the same application 
> is deployed to 2.0-M6 following exception is thrown:
> {noformat}
> 15:57:53,267 INFO  [DirectoryHotDeployer] Deploying proximity
> 15:57:56,690 WARN  [JettyModuleBuilder] Web application . does not contain a 
> WEB-INF/geronimo-web.xml deployment plan.  This may or may not be a problem, 
> depending on whether you have things like resource references that need to be 
> resolved.  You can also give the deployer a separate deployment plan file on 
> the command line.
> 15:58:04,709 WARN  [JspModuleBuilderExtension] Invalid transformed taglib
> org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors:
> jar:file:/opt/geronimo-jetty6-jee5-2.0-M6/repository/default/proximity/1185307073730/proximity-1185307073730.war/WEB-INF/lib/bsf-2.3.0.jar!/META-INF/taglib.tld:15:3:
>  error: cvc-datatype-valid.1.1: string value 'BSF JSP Support' does not match 
> pattern for tld-canonical-nameType in namespace 
> http://java.sun.com/xml/ns/javaee
> Descriptor:
> 
> http://java.sun.com/xml/ns/javaee  
> http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd"; version="2.1" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns="http://java.sun.com/xml/ns/javaee";>
>   

[jira] Updated: (GERONIMO-3240) Unable to obtain physical connection to jdbc:derby:

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3240:
---

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

updated Fixed For field

> Unable to obtain physical connection to jdbc:derby:
> ---
>
> Key: GERONIMO-3240
> URL: https://issues.apache.org/jira/browse/GERONIMO-3240
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.0-M6
> Environment: Geronimo v2.0-M6-rc3
>Reporter: Hernan Cunico
> Fix For: 2.0.1, 2.1
>
> Attachments: geronimo-3240.patch
>
>
> Created a sample db on the embedded Derby database using the admin console. 
> Created a connection pool to that database with the wizard, the "Test 
> Connection" works fine during pool creation.
> When I try to access that pool from an application I get an error as if the 
> database wouldn't exists.
> 13:28:24,218 ERROR [MCFConnectionInterceptor] Error occurred creating 
> ManagedConnection for [EMAIL PROTECTED]
> javax.resource.spi.ResourceAllocationException: Unable to obtain physical 
> connection to jdbc:derby:sample
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDriverMCF.java:98)
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.createManagedConnection(JDBCDriverMCF.java:73)
> at 
> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getConnection(MCFConnectionInterceptor.java:48)
> at 
> org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterceptor.getConnection(LocalXAResourceInsertionInterceptor.java:41)
> at 
> org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor.internalGetConnection(SinglePoolConnectionInterceptor.java:66)
> at 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
> at 
> org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:46)
> at 
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.getConnection(TransactionCachingInterceptor.java:95)
> at 
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:43)
> at 
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39)
> at 
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.getConnection(ConnectionTrackingInterceptor.java:66)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:61)
> at 
> org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56)
> at 
> org.apache.geronimo.samples.dbtester.beans.DBManagerBean.getTableList(DBManagerBean.java:76)
> at 
> org.apache.geronimo.samples.dbtester.web.ListTablesServlet.listTables(ListTablesServlet.java:32)
> at 
> org.apache.geronimo.samples.dbtester.web.ListTablesServlet.doGet(ListTablesServlet.java:17)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:358)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
> at 
> org.apache.tomc

[jira] Commented: (GERONIMO-3423) Ensure that users can change the ejb jndi name format

[Donald Woods (JIRA)]

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

Donald Woods commented on GERONIMO-3423:


Was this also fixed in the 2.0 branch (aka. 2.0.2) ???
There is no subversion history to go on

> Ensure that users can change the ejb jndi name format
> -
>
> Key: GERONIMO-3423
> URL: https://issues.apache.org/jira/browse/GERONIMO-3423
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0, 2.0.x
>Reporter: David Blevins
>Assignee: David Blevins
> Fix For: 2.0.x, 2.1
>
>
> Right now OpenEjbSystemGBean is hard coded to always set a value for 
> "openejb.jndiname.format".  We should check to see if it's set first and if 
> so, not reset it.  We should log a warning message if it's changed that 
> javaee app client's will not work.

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

Re: XML Schemas

[Hernan Cunico]

would this plugin be smart enough to place/rename the schemas in the right 
"directory" accordingly to what's specified as the target name space?

Cheers!
Hernan

Donald Woods wrote:

Nope, but sounds like a good job for the maven-release-plugin :-)


-Donald

Hernan Cunico wrote:

Hi All,
trying to deal with the schemas update on the web site and I'm looking 
to some things I would like to get your input.


First of all the actual schemas file name don't match the target name 
space defined in the schema itself.


Here is the associated JIRA ( 
https://issues.apache.org/jira/browse/GERONIMO-3425 ). This is mainly 
for updating the web site but I think it would be more clear for 
everybody to have matching names anyway.
Is it feasible/practical to have the schemas file names match the name 
space?


Second, in order to have the schemas available on a target's name 
space matching URL (http://geronimo.apache.org/xml/ns ...) we need to 
have and maintain up-to-date copy a the schemas on the web site trunk.


We currently have the schemas scattered all over the server trunk. 
Last time Jarek manually copied the files over but clearly this can 
not be a manual task.


Anybody has any ideas for having this automatically updated?

Cheers!
Hernan

Re: XML Schemas

[Donald Woods]

Nope, but sounds like a good job for the maven-release-plugin :-)


-Donald

Hernan Cunico wrote:

Hi All,
trying to deal with the schemas update on the web site and I'm looking 
to some things I would like to get your input.


First of all the actual schemas file name don't match the target name 
space defined in the schema itself.


Here is the associated JIRA ( 
https://issues.apache.org/jira/browse/GERONIMO-3425 ). This is mainly 
for updating the web site but I think it would be more clear for 
everybody to have matching names anyway.
Is it feasible/practical to have the schemas file names match the name 
space?


Second, in order to have the schemas available on a target's name space 
matching URL (http://geronimo.apache.org/xml/ns ...) we need to have and 
maintain up-to-date copy a the schemas on the web site trunk.


We currently have the schemas scattered all over the server trunk. Last 
time Jarek manually copied the files over but clearly this can not be a 
manual task.


Anybody has any ideas for having this automatically updated?

Cheers!
Hernan




smime.p7s
Description: S/MIME Cryptographic Signature

Re: XML Schemas on the site

[Ted Kirby]

On 9/19/07, David Blevins <[EMAIL PROTECTED]> wrote:
>
> On Sep 18, 2007, at 7:07 AM, Hernan Cunico wrote:
>
> > I talked with Dave Blevins about this, maybe I got it wrong. Dave
> > can you take a look at this?
>
> We should still use the same schema from G 1.2 for now.  There's a
> lot of documentation for it, it's used in the tck, the j2g tool uses
> it.  It's not going anywhere for long while :)
>
> Along those lines, I was helping out a user on irc and wanted to show
> them the openejb-jar.xml doc but there's no xml in it.
>
> http://cwiki.apache.org/GMOxDOC12/openejb-jarxml.html
>
> What happened to it?

It looks like the xml (code) blocks were removed in rev 17 back in
January.  I dunno why.  I took the liberty of adding them back.  You
may well want to review them.

Ted Kirby

> -David
>
>
> >
> > Cheers!
> > Hernan
> >
> > Shiva Kumar H R wrote:
> >> What's the correct Geronimo Schema for EJB (JAR)? Is it not http://
> >> geronimo.apache.org/xml/ns/j2ee/ejb/openejb-2.0 ??
> >> - Shiva
> >> On 9/18/07, *Hernan Cunico* <[EMAIL PROTECTED]
> >> > wrote:
> >> I've updated the XML Schemas info on the web site for reflect
> >> 1.0,
> >> 1.1 and 2.0
> >> You can take a quick look at the new organization here
> >> http://cwiki.apache.org/GMOxSITE/xml-schemas.html
> >> 
> >> Changes will get reflected on the live site within the next hour.
> >> Cheers!
> >> Hernan
> >> Hernan Cunico wrote:
> >>  > Folks,
> >>  > This is what we have so far for the schemas, note that
> >> openEJB is
> >> still
> >>  > pending
> >>  >
> >>  > http://cwiki.apache.org/GMOxSBOX/schemas-20.html
> >>  >
> >>  > Thanks Jarek for consolidating the schemas on svn
> >>  >
> >>  > Pls take a look and send in your comments.
> >>  >
> >>  >
> >>  > Cheers!
> >>  > Hernan
> >>  >
> >>  > Hernan Cunico wrote:
> >>  >> YES. I think Jarek already moved all the schemas
> >>  >> (
> >> https://svn.apache.org/repos/asf/geronimo/site/trunk/docs/
> >> schemas-2.0/)
> >>  >> so I'll be updating the web site soon.
> >>  >>
> >>  >> Cheers!
> >>  >> Hernan
> >>  >>
> >>  >> Anita Kulshreshtha wrote:
> >>  >>>Are there any plans to put the schemas for 2.0.1 here:
> >>  >>> http://geronimo.apache.org/xml-schemas.html
> >>  >>>
> >>  >>> Thanks
> >>  >>> Anita
> >>  >>>
> >>  >>>
> >>  >>>
> >>  >>>
> >>  >>>
> >>
> >> _
> >> ___
> >>  >>>
> >>  >>> Need a vacation? Get great deals
> >>  >>> to amazing places on Yahoo! Travel.
> >>  >>> http://travel.yahoo.com/
> >>  >>>
> >>  >>
> >>  >
> >
>
>

[jira] Updated: (GERONIMO-3360) corba-marshall and corba-mytime tests failing

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3360:
---

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

updated Fixed For field

> corba-marshall and corba-mytime tests failing
> -
>
> Key: GERONIMO-3360
> URL: https://issues.apache.org/jira/browse/GERONIMO-3360
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: testsuite
>Affects Versions: 2.0, 2.0.x, 2.1
>Reporter: Prasad Kashyap
>Assignee: Rick McGuire
> Fix For: 2.0, 2.0.1, 2.1
>
>
> exception in corba-marshall :
> {code}
> [INFO] [INFO] long passed to EJB: 1218738708599296309
> [INFO] [WARNING] java.lang.Exception: long array test RemoteException: 
> [3675022138608874094, -4905270342012320510] java.rmi.RemoteException: null; 
> nested exception is: 
> [INFO] [WARNING]  org.omg.CORBA.UNKNOWN:  vmcid: 0x0 minor code: 0x0  
> completed: No
> [INFO] [WARNING]  at 
> org.apache.geronimo.testsuite.corba.marshal.JavaPrimitives.marshal(JavaPrimitives.java:415)
> [INFO] [WARNING]  at 
> org.apache.geronimo.testsuite.corba.marshal.MarshalEJBClient.main(MarshalEJBClient.java:43)
> [INFO] [WARNING]  at java.lang.reflect.Method.invoke(Method.java:585)
> [INFO] [WARNING]  at 
> org.apache.geronimo.client.AppClientContainer.main(AppClientContainer.java:185)
> {code}
> Exception in corba-mytime:
> {code}
> [WARNING] Deployer operation failed: start of 
> org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
> [WARNING] org.apache.geronimo.kernel.config.LifecycleException: start of 
> org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
> [WARNING] Caused by: 
> org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start 
> exception
> [WARNING] at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:514)
> [WARNING] at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
> [WARNING] at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
> [WARNING] ... 35 more
> [WARNING] Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: 
> Configuration org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car 
> failed to start due to the following reasons:
> [WARNING]   The service 
> EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,StatelessSessionBean=MyTime,j2eeType=TSSLink,name=IdentityTokenNoSecurity
>  did not start because 
> org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car?EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
>  did not start.
> [WARNING]   The service 
> EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
>  did not start because IDL:omg.org/PortableServer/POA/AdapterAlreadyExists:1.0
> [WARNING] 
> {code}

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

[jira] Updated: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-2567:
---

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

updated Fixed For field

> Remote admin of server using deployer.jar fails to connect
> --
>
> Key: GERONIMO-2567
> URL: https://issues.apache.org/jira/browse/GERONIMO-2567
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.2, 2.0, 2.0.x
> Environment: Linux
> Java 1.5
>Reporter: Jay D. McHugh
>Assignee: Kevan Miller
> Fix For: 2.0.2, 2.1
>
>
> Trying to remote deploy a WAR file resulted in a failed connection.
> This happened regardless of whether the port was specified.
> $ java -jar deployer.jar --user system --password manager --host 172.16.1.41 
> redeploy ~/PaLM.war
> Error: Unable to connect to server at
> deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host:
> 127.0.0.1; nested exception is:
> java.net.ConnectException: Connection refused

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

[jira] Updated: (GERONIMO-3401) Stop of module from "System Modules" in console should warn user of destructive action

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3401:
---

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

updated Fixed For field

> Stop of module from "System Modules" in console should warn user of 
> destructive action
> --
>
> Key: GERONIMO-3401
> URL: https://issues.apache.org/jira/browse/GERONIMO-3401
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0, 2.0.x
> Environment: Geronimo 2.0.1-SNAPSHOT using Tomcat JEE assembly.  Most 
> likely affects others as well
>Reporter: Matt Hogstrom
>Assignee: Joe Bohn
> Fix For: 2.0.2, 2.1
>
>
> When using the Geronimo Console to stop of a module a 404 is received in the 
> console.  In this case an attempt to stop OpenEJB.  The console then becomes 
> unusable and also does not survive a restart.  It appears the console needs 
> to be re-installed.
> {panel:title=Error reported to Browser| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE} 
> HTTP Status 404 - 
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> type Status report
> message 
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> description The requested resource 
> (/console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view)
>  is not available.
> {panel}
> {panel:title=Exception LoggedMy Title| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE}
> [] received stop signal
> 00:59:03,833 ERROR [Servlet] Exception caught: 
> org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid 
> to gbean: 
> org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car,j2eeType=JCAConnectionTracker,name=ConnectionTracker
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
> at 
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$4301e6fc.exit()
> at 
> org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.after(InstanceContextBeforeAfter.java:73)
> at 
> org.apache.geronimo.tomcat.interceptor.ComponentContextBeforeAfter.after(ComponentContextBeforeAfter.java:46)
> at 
> org.apache.geronimo.tomcat.interceptor.PolicyContextBeforeAfter.after(PolicyContextBeforeAfter.java:70)
> at 
> org.apache.geronimo.tomcat.interceptor.UserTransactionBeforeAfter.after(UserTransactionBeforeAfter.java:47)
> at 
> org.apache.geronimo.tomcat.listener.DispatchListener.afterDispatch(DispatchListener.java:86)
> at 
> org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(DispatchListener.java:59)
> at 
> org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:275)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:682)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
> at 
> org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
> at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
> at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubje

[jira] Updated: (GERONIMO-3407) SubjectRegistrationLoginModule conceptually can't work.

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3407:
---

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

updated Fixed For field

> SubjectRegistrationLoginModule conceptually can't work.
> ---
>
> Key: GERONIMO-3407
> URL: https://issues.apache.org/jira/browse/GERONIMO-3407
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0, 2.0.x, 2.1
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.1, 2.1
>
>
> The idea of SubjectRegistrationLoginModule while attractive just can't work.  
> The idea behind subject registration is that we want to compute the 
> AccessControlContext for a subject once and cache it.  That can only be done 
> once the subject is fully populated by all login modules, so if the ACC is 
> determined by a login module it must be the last one.  However, if any 
> previous LM is marked REQUISITE no further modules will be processed.  
> Therefore we have to register the subjects in some other way.  Just maybe we 
> could "preregister" the subject but determine the ACC lazily??

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

[jira] Updated: (GERONIMO-3406) "Auxilliary" login modules are mostly returning true instead of false

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3406:
---

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

updated Fixed For field

> "Auxilliary" login modules are mostly returning true instead of false
> -
>
> Key: GERONIMO-3406
> URL: https://issues.apache.org/jira/browse/GERONIMO-3406
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0, 2.0.x, 2.1
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.1, 2.1
>
>
> We have several login modules that don't do security checks but do look at 
> and sometimes modify the Subject.  These should never be able to result in a 
> login succeeding, so they should be returning false from the various 
> lifecycle methods.
> In a slightly related issue the SubjectRegistrationLoginModule should be 
> first in the list so it will always get executed even if one of the other 
> login modules is REQUISITE.  This might mean we need to rethink if 
> SubjectRegistrationLoginModule is an appropriate way to get the registration 
> to happen.

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

[jira] Updated: (GERONIMO-2286) app client plan still uses Strings for dependency Module IDs

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-2286:
---

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

updated Fixed For field

> app client plan still uses Strings for dependency Module IDs
> 
>
> Key: GERONIMO-2286
> URL: https://issues.apache.org/jira/browse/GERONIMO-2286
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: application client, deployment
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Assignee: David Jencks
> Fix For: 2.0
>
>
> The geronimo-application-client schema has:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> That would typically be used like this:
>   
> tranql/tranql-connector/1.2/rar
>
> Everywhere else we've changed elements holding module IDs to be of 
> patternType, using separate groupId, artifactId, version, and type elements.  
> There's no reason external-rar should still be a single slash-delimited 
> String here (though internal-rar should be since it's presumably a path 
> within the JAR?).

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

[jira] Updated: (GERONIMO-3385) PluginInstaller thinks servers must be under var and doesn't trim paths

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3385:
---

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

updated Fixed For field

> PluginInstaller thinks servers must be under var and doesn't trim paths
> ---
>
> Key: GERONIMO-3385
> URL: https://issues.apache.org/jira/browse/GERONIMO-3385
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 2.0
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.1, 2.1
>
>
> 2 problems in PluginInstallerGBean:
> - does not trim copy-file in geronimo-plugin.xml
> - prepends "var/" to copy-file destination

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

[jira] Updated: (GERONIMO-3387) Unable to deploy an ear file (that contains a war file) if web.xml isn't supplied in the war file

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3387:
---

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

updated Fixed For field

> Unable to deploy an ear file (that contains a war file) if web.xml isn't 
> supplied in the war file
> -
>
> Key: GERONIMO-3387
> URL: https://issues.apache.org/jira/browse/GERONIMO-3387
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0.x
> Environment: winxp + sun 1.5 JDK
>Reporter: Lin Sun
>Assignee: Lin Sun
> Fix For: 2.0.1, 2.1
>
> Attachments: G3387.patch
>
>
> I have an ear file that contains a war file.   I have a 
> geronimo-application.xml for the ear file.   The war file doesn't have 
> web.xml as it is optional with JEE 5.
> I got the following failure at deployment -
> Error: Unable to distribute SOAPBench.ear: Module was not a war:
> SOABenchWeb.war
> Looks like this is caused by the fact that moduleFile didn't created 
> correctly in line 762 of EARConfigBuilder.java.   Its name didn't have the 
> extension of .war that TomcatModuleBuilder is expecting.
> moduleFile = new NestedJarFile(earFile, modulePath);
> One possible fix is to allow an extension to be passed in createTempFile in 
> DeploymentUtils.java, like the createTempFile in 
> org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.java.   But 
> there could be other way that is better.

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

[jira] Updated: (GERONIMO-895) Remove JAAS login's reliance on remote JMX

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-895:
--

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

updated Fixed For field

> Remove JAAS login's reliance on remote JMX
> --
>
> Key: GERONIMO-895
> URL: https://issues.apache.org/jira/browse/GERONIMO-895
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 1.0-M4
>Reporter: Alan Cabrera
>Assignee: David Jencks
> Fix For: 2.0, 2.1
>
>
> Remove JAAS login's reliance on remote JMX.  Ideally, using something 
> pluggable would be great.

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

[jira] Closed: (GERONIMO-3363) ArrayList thread safe problem in OpenJPA

[Donald Woods (JIRA)]

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

Donald Woods closed GERONIMO-3363.
--

   Resolution: Fixed
Fix Version/s: (was: 2.0.x)
   2.1
   2.0.2

Fixed in OpenJPA right after we cut our revision for 2.0/2.0.1 release.
By picking up the final 1.0.0 release, we will have the fix.

> ArrayList thread safe problem in OpenJPA
> 
>
> Key: GERONIMO-3363
> URL: https://issues.apache.org/jira/browse/GERONIMO-3363
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: persistence
>Affects Versions: 2.0
>Reporter: YunFeng Ma
>Assignee: Donald Woods
> Fix For: 2.0.2, 2.1
>
>
> When running stress testing using DayTrader with JPA mode, got a lot of 
> ArrayList thread safe problem.
> The thread safe problem happened in  
> org.apache.openjpa.kernel.AbstractBrokerFactory.syncWithManagedTransaction, 
> but this method has the following comments:
> // we don't need to synchronize on brokers or guard against 
> multiple
> // threads using the same trans since one JTA transaction can 
> never
> // be active on multiple concurrent threads.
> Collection brokers = (Collection) _transactional.get(trans);
> if (brokers == null) {
> brokers = new ArrayList(2);
> _transactional.put(trans, brokers);
> trans.registerSynchronization(new 
> RemoveTransactionSync(trans));
> }
> brokers.add(broker);
> Does this mean that it's Geronimo which causes the thread safe problem?
> The exception stack:
> java.rmi.RemoteException: The bean encountered a non-application exception.; 
> nested exception is:
> javax.ejb.EJBException: TradeBean.getClosedOrders - error
> at 
> org.apache.openejb.core.transaction.TransactionPolicy.throwExceptionToServer(TransactionPolicy.java:211)
> at 
> org.apache.openejb.core.transaction.TxRequired.handleSystemException(TxRequired.java:106)
> at 
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210)
> at 
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
> at 
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:211)
> at 
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:65)
> at 
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:232)
> at 
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> at $Proxy109.getClosedOrders(Unknown Source)
> at 
> org.apache.geronimo.samples.daytrader.TradeAction.getClosedOrders(TradeAction.java:276)
> at 
> org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:76)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:801)
> Caused by: javax.ejb.EJBException: TradeBean.getClosedOrders - error
> at 
> org.apache.geronimo.samples.daytrader.TradeJPA.getClosedOrders(TradeJPA.java:491)
> at sun.reflect.GeneratedMethodAccessor324.invoke(Unknown Source)

[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-2964:
---

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

> Cannot specify the Tomcat work directory for a web application
> --
>
> Key: GERONIMO-2964
> URL: https://issues.apache.org/jira/browse/GERONIMO-2964
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.2, 2.0-M5
>Reporter: Aman Nanner
>Assignee: Vamsavardhana Reddy
>Priority: Minor
> Fix For: 2.0.2, 2.1
>
> Attachments: g2964.war, GERONIMO-2964-2.0-w-cons-change.patch, 
> GERONIMO-2964-2.0.patch, GERONIMO-2964-combined-new.patch, 
> GERONIMO-2964-combined.patch, GERONIMO-2964-trunk.patch, GERONIMO-2964.patch, 
> suid.patch, tomcat-config-workdir.patch, tomcat-workdir.patch
>
>
> In Tomcat, a work directory can be specified for a web application in a 
> WEB-INF/context.xml file.  The GeronimoStandardContext does not permit the 
> user to specify a work directory, and so the work directory defaults to 
> var/catalina/work/.
> I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to 
> permit the user to optionally specify a work directory.  This work directory 
> is then propagated into the TomcatContext.  I've tested this and it seems to 
> work well.

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

[jira] Updated: (GERONIMO-2025) Undeploy and redeploy with no version leaves dangling entries in config.xml

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-2025:
---

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

> Undeploy and redeploy with no version leaves dangling entries in config.xml
> ---
>
> Key: GERONIMO-2025
> URL: https://issues.apache.org/jira/browse/GERONIMO-2025
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, kernel
>Affects Versions: 1.1, 2.0.x, 2.1
>Reporter: Aaron Mulder
>Assignee: Rakesh Midha
> Fix For: 2.0.2, 2.1
>
> Attachments: removeunwantedconfig.patch
>
>
> If you deploy an application with no version and then undeploy it, we leave 
> an entry for it (with a timestamp version number) in config.xml, just marked 
> as load=false.
> If you later deploy the application again, you get a new timestamp version 
> number and a new entry is written into config.xml.  Do this (undeploy/deploy) 
> a few times and config.xml gets kind of messy.
> It would be be good to delete entries from config.xml on undeploy if they 
> have no actual settings.
> It would be good to detect that a previous version is in conifg.xml but not 
> in the repository and delete the settings from config.xml if the artifact has 
> no version number and a newer copy is deployed.
> This is not a huge priority since nothing breaks, it just makes config.xml 
> kind of crufty.

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

[jira] Updated: (GERONIMO-2025) Undeploy and redeploy with no version leaves dangling entries in config.xml

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-2025:
---

Affects Version/s: 2.1
   2.0.x

updated affects field

> Undeploy and redeploy with no version leaves dangling entries in config.xml
> ---
>
> Key: GERONIMO-2025
> URL: https://issues.apache.org/jira/browse/GERONIMO-2025
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, kernel
>Affects Versions: 1.1, 2.0.x, 2.1
>Reporter: Aaron Mulder
>Assignee: Rakesh Midha
> Fix For: 2.0.x
>
> Attachments: removeunwantedconfig.patch
>
>
> If you deploy an application with no version and then undeploy it, we leave 
> an entry for it (with a timestamp version number) in config.xml, just marked 
> as load=false.
> If you later deploy the application again, you get a new timestamp version 
> number and a new entry is written into config.xml.  Do this (undeploy/deploy) 
> a few times and config.xml gets kind of messy.
> It would be be good to delete entries from config.xml on undeploy if they 
> have no actual settings.
> It would be good to detect that a previous version is in conifg.xml but not 
> in the repository and delete the settings from config.xml if the artifact has 
> no version number and a newer copy is deployed.
> This is not a huge priority since nothing breaks, it just makes config.xml 
> kind of crufty.

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

[jira] Updated: (GERONIMO-3411) injection target entries are not added to existing env-entry entries

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3411:
---

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

updated Fixed For field

> injection target entries are not added to existing env-entry entries
> 
>
> Key: GERONIMO-3411
> URL: https://issues.apache.org/jira/browse/GERONIMO-3411
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0, 2.1
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
> Fix For: 2.0.1, 2.0.2, 2.1
>
>
> I have a basic env-entry defined in web.xml file. My service also has 
> @Resource defined for that env-entry. The value of the env-entry is not 
> injected at runtime. 

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

XML Schemas

[Hernan Cunico]

Hi All,
trying to deal with the schemas update on the web site and I'm looking to some 
things I would like to get your input.

First of all the actual schemas file name don't match the target name space 
defined in the schema itself.

Here is the associated JIRA ( https://issues.apache.org/jira/browse/GERONIMO-3425 ). This is mainly for updating the web site but I think it would be more clear for everybody to have matching names anyway. 


Is it feasible/practical to have the schemas file names match the name space?

Second, in order to have the schemas available on a target's name space 
matching URL (http://geronimo.apache.org/xml/ns ...) we need to have and 
maintain up-to-date copy a the schemas on the web site trunk.

We currently have the schemas scattered all over the server trunk. Last time 
Jarek manually copied the files over but clearly this can not be a manual task.

Anybody has any ideas for having this automatically updated?

Cheers!
Hernan

[jira] Updated: (GERONIMO-3435) Axis2: unable to create a service-ref without wsdl using a generic Service class

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3435:
---

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

updated Fixed For field

> Axis2: unable to create a service-ref without wsdl using a generic Service 
> class
> 
>
> Key: GERONIMO-3435
> URL: https://issues.apache.org/jira/browse/GERONIMO-3435
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.0, 2.1
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
> Fix For: 2.0.2, 2.1
>
>
> When Axis2 JAX-WS engine is used a service-ref without wsdl using a generic 
> Service class cannot be created. An error is raised because service qname is 
> expected. 

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

[jira] Updated: (GERONIMO-3414) servlet.destroy() not called on POJOWebServiceServlet

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3414:
---

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

updated Fixed For field

> servlet.destroy() not called on POJOWebServiceServlet
> -
>
> Key: GERONIMO-3414
> URL: https://issues.apache.org/jira/browse/GERONIMO-3414
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Jetty
>Affects Versions: 2.0.1, 2.1
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
> Fix For: 2.0.2, 2.1
>
>
> It appears like the destroy() method is not invoked on POJOWebServiceServlet 
> on Jetty. This works fine on Tomcat.

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

[jira] Updated: (GERONIMO-3426) The Holder object contains duplicated injections

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3426:
---

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

updated Fixed For field

> The Holder object contains duplicated injections
> 
>
> Key: GERONIMO-3426
> URL: https://issues.apache.org/jira/browse/GERONIMO-3426
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 2.0, 2.1
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
> Fix For: 2.0.2, 2.1
>
>
> The Holder object contains duplicated injections and so when actual injection 
> is performed the objects are looked up in the JNDI twice. This happens 
> because the NamingBuilders are executed twice - see GERONIMO-3359.
> A simple fix for this problem is to change the Holder implementation to 
> remove the duplicates.

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

[jira] Updated: (GERONIMO-3410) jspc-maven-plugin-2.0-alpha-1 is causing build failures on Windows

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3410:
---

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

> jspc-maven-plugin-2.0-alpha-1 is causing build failures on Windows
> --
>
> Key: GERONIMO-3410
> URL: https://issues.apache.org/jira/browse/GERONIMO-3410
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 2.0, 2.0.x
> Environment: WinXP
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Critical
> Fix For: 2.0.1
>
>
> http://repository.codehaus.org/org/codehaus/mojo/jspc/jspc-compiler
> -tomcat6/2.0-alpha-1/jspc-compiler-tomcat6-2.0-alpha-1.jar
> 4K downloaded
> [INFO] [jspc:compile {execution: default}]
> [INFO]
> 
> [ERROR] FATAL ERROR
> [INFO]
> 
> [INFO] null
> Illegal character in path at index 18: file:/C:/Documents and
> Settings/Anita/.m2
> /repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
> [INFO]
> 
> [INFO] Trace
> java.lang.IllegalArgumentException
>at java.net.URI.create(URI.java:842)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> The jspc-maven-plugin-2.0-alpha-1.jar is to blame. I still had a copy of the 
> last alpha-1-SNAPSHOT laying around 
> (jspc-maven-plugin-2.0-alpha-1-20070806.170854-1.jar) and copied it over the 
> released alpha-1.jar from 8/8 and my builds starting working again on 
> WinXP

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

[jira] Updated: (GERONIMO-3404) Using a Null Username allows access to a running 2.0 server

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3404:
---

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

> Using a Null Username allows access to a running 2.0 server
> ---
>
> Key: GERONIMO-3404
> URL: https://issues.apache.org/jira/browse/GERONIMO-3404
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0, 2.1
> Environment: Released geronimo-tomcat6-jee5-2.0-bin.zip on WinXP and 
> on Linux
>Reporter: Donald Woods
>Assignee: David Jencks
>Priority: Critical
> Fix For: 2.0.1, 2.1
>
> Attachments: GERONIMO-3404.patch
>
>
> I was just testing the geronimo-tomcat6-jee5-2.0-bin.zip on a new WinXP 
> machine and discovered that anyone can administer a Geronimo server (local or 
> remotely) if they enter a null Username when prompted by the deploy or 
> geronimo scripts.  I verified that the \.geronimo-deployer file 
> did not exist on the WinXP machine and on a Linux box I used to verify the 
> remote scenario 

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

[jira] Updated: (GERONIMO-3439) geronimo-openejb-2.0.xsd not packaged under schema directory!

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3439:
---

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

updated Fixed For field

> geronimo-openejb-2.0.xsd not packaged under schema directory!
> -
>
> Key: GERONIMO-3439
> URL: https://issues.apache.org/jira/browse/GERONIMO-3439
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0, 2.0.1, 2.1
>Reporter: Shiva Kumar H R
>Assignee: Jarek Gawor
> Fix For: 2.0.2, 2.1
>
>
> geronimo-openejb-2.0.xsd is currently hidden inside 
> repository\org\apache\geronimo\modules\geronimo-security-builder\2.0.1\geronimo-security-builder-2.0.1.jar

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

[jira] Updated: (GERONIMO-3459) Build break due to OpenEJB Rev572863 changes

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3459:
---

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

updated Fixed For field

> Build break due to OpenEJB Rev572863 changes
> 
>
> Key: GERONIMO-3459
> URL: https://issues.apache.org/jira/browse/GERONIMO-3459
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0.2, 2.1
>Reporter: Donald Woods
>Assignee: David Blevins
>Priority: Blocker
> Fix For: 2.0.2, 2.1
>
>
> Trunk and 2.0.2-SNAPSHOT builds are failing due to changes in OpenEJB 
> Rev572863 to removed some "unused" code.
> [INFO] 
> 
> [INFO] Building Geronimo :: CORBA
> [INFO]task-segment: [install]
> [INFO] 
> 
> [INFO] [enforcer:enforce {execution: default}]
> [INFO] [tools:copy-legal-files {execution: install-legal-files}]
> [INFO] Created dir: 
> /home/prasad/geronimo/2.0/modules/geronimo-corba/target/classes/META-INF
> [INFO] Copying 2 files to 
> /home/prasad/geronimo/2.0/modules/geronimo-corba/target/classes/META-INF
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 123 source files to 
> /home/prasad/geronimo/2.0/modules/geronimo-corba/target/classes
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Compilation failure
> /home/prasad/geronimo/2.0/modules/geronimo-corba/src/main/java/org/apache/geronimo/corba/util/Util.java:[73,31]
>  cannot find symbol
> symbol  : class ObjectInputStreamExt
> location: package org.apache.openejb.util
> /home/prasad/geronimo/2.0/modules/geronimo-corba/src/main/java/org/apache/geronimo/corba/util/Util.java:[557,8]
>  cannot find symbol
> symbol  : class ObjectInputStreamExt
> location: class org.apache.geronimo.corba.util.Util
> /home/prasad/geronimo/2.0/modules/geronimo-corba/src/main/java/org/apache/geronimo/corba/util/Util.java:[557,39]
>  cannot find symbol
> symbol  : class ObjectInputStreamExt
> location: class org.apache.geronimo.corba.util.Util

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

Re: [DISCUSS] G 2.0.2 Release plan

[Donald Woods]

BTW - I'm going through JIRA today and updating any Fix For: 2.0.x 
closed/resolved issues to use the correct release attribute, so we can 
generate a valid list of fixes for the 2.0.2 release notes


-Donald

Kevan Miller wrote:

All,
I think it's time to start rolling out a 2.0.2 release. There have been 
a number of fixes in response to user issues, since 2.0.1. Time, I 
think, to make these available in a release. We'd also be able to make 
use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, 
whittling away at our local builds...


I think we have one must-fix problem that is outstanding -- the MEJB 
security issue. Assuming we resolve this problem, are there any other 
issues which must be resolved prior to a 2.0.2 release?


Assuming we're in general agreement, I'd set a goal of creating a 
release candidate by next Friday (Sept 21). I'm volunteering to be the 
release manager.


Thoughts?

--kevan




smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Updated: (GERONIMO-3467) Confusing security exception thrown while authenticating using JMX with a just starting server

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3467:
---

Affects Version/s: 2.1
Fix Version/s: 2.1

> Confusing security exception thrown while authenticating using JMX with a 
> just starting server
> --
>
> Key: GERONIMO-3467
> URL: https://issues.apache.org/jira/browse/GERONIMO-3467
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0.2, 2.1
>Reporter: Shiva Kumar H R
> Fix For: 2.0.2, 2.1
>
>
> Scenario is as below:
> Let's say server is starting and 
> org.apache.geronimo.configs/rmi-naming/2.0.1/car has started, but 
> org.apache.geronimo.configs/j2ee-security/2.0.1/car hasn't yet started. If an 
> external entity (like Geronimo Eclipse Plug-in) now tries to connect to the 
> kernel remotely through JMX, although rmi connection succeeds, authenticate 
> will fail (because security realm has not yet been started).
> In this case, org.apache.geronimo.jmxremoting.Authenticator.authenticate() is 
> getting a LoginException with error 
> "javax.security.auth.login.LoginException: No LoginModules configured for 
> geronimo-admin". However this exception is not propogated, but rather is 
> thrown back as a 'SecurityException("Invalid login")'.

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

Re: Should the geronimo-activation module be rolled into the javamail providers?

[Donald Woods]

Sounds good.  +1

-Donald

Rick McGuire wrote:
I ran into a situation where somebody wishing to use the Geronimo 
javamail implementation also need to extract the geroinimo-activation 
jar file from the server assembly.  This was needed because the various 
activation datahandlers are not included in the mail uber-jar that gets 
built.  I thought this problem had been fixed when the uber jar had been 
created, but there were other classes I didn't really know about until 
this came up.
So, currently, to using the Sun javamail implementation requires 2 jar 
files, mail.jar and activation .jar.  To use the Geronimo version with 
equivalent function, you need the Geronimo activation spec jar, the 
Geronimo javamail mail jar (which includes the javamail spec and 
javamail providers), AND the geronimo-activation-1.0 jar, which adds in 
data source handlers that that Sun includes in their mail.jar.
This is a bit awkward, as the spec jars and the provider jars are built 
outside of Geronimo, while the geronimo-activation module is part of the 
server build, even though it is code that's completely independent of 
Geronimo (no dependencies on Geronimo code at all).


Based on Sun's precedent, and what we did earlier with the javamail 
provider code (formerly the geronimo-javamail-transport module), the 
code in the current geronimo-activation module should be moved to the 
javamail provider code tree so that all of these classes get bundled in 
the jar file that makes up the javamail implementation.

Are there any objects to doing this?

Rick




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Anyone want to smoke test tranql adapters?

[Donald Woods]

Agree.

-Donald

Lin Sun wrote:
David, I tried both the local and xa rars for oracle and it works good 
with daytrader (without any issue in G2188).   I have a question on the 
local and xa rars.   Is there any reason why we want to continue 
releasing the local rars?  Seems it is rather confusing to have so many 
rars for a user to select...


Lin

David Jencks wrote:
I made one code change and a whole lot of build cleanup in the tranql 
adapters and I'd like to release them, but I'm not set up to try most 
of them out at all.  Is anyone able to give any of them a try?


We have..

generic
db2
derby
mysql
oracle
postgres

IIUC Matt's going to try to do at least the db2 connectors and maybe 
mysql.  If anyone want to try out one of the others let me know and 
I'll send them to you (or you can build from trunk, although the 
sequence of stuff to build may be a bit hard to figure out)


thanks
david jencks








smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Updated: (GERONIMO-1746) Cannot override default configurationFile value in Log4jService GBean

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-1746:
---

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

> Cannot override default configurationFile value in Log4jService GBean
> -
>
> Key: GERONIMO-1746
> URL: https://issues.apache.org/jira/browse/GERONIMO-1746
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console, Logging
>Affects Versions: 1.0, 2.0, 2.1
> Environment: Win XP, Sun JDK 1.4.2_08
>Reporter: Vamsavardhana Reddy
>Assignee: Donald Woods
> Fix For: 2.0.2, 2.1
>
>
> Changes made to the logger through Log Manager portlet are not reflected in 
> the server.  Through the admin console, I have changed the Config File from 
> server-log4j.properties to a different file.  The change is written to 
> config.xml .  Inspite of this new file name in config.xml, upon restart, the 
> server still uses server-log4j.properties  .
> Restarting the server after deleting server-log4j.properties logged the 
> following error to console window.
> log4j:ERROR Could not read configuration file from URL 
> [file:/C:/geronimo-1.0/va
> r/log/server-log4j.properties].
> java.io.FileNotFoundException: 
> C:\geronimo-1.0\var\log\server-log4j.properties (
> The system cannot find the file specified)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(Unknown Source)
> at java.io.FileInputStream.(Unknown Source)
> at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
> at sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown 
> So
> urce)
> at java.net.URL.openStream(Unknown Source)
> at 
> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurato
> r.java:424)
> at 
> org.apache.geronimo.system.logging.log4j.URLConfigurator.doConfigure(
> URLConfigurator.java:117)
> at 
> org.apache.geronimo.system.logging.log4j.URLConfigurator.configure(UR
> LConfigurator.java:44)
> at 
> org.apache.geronimo.system.logging.log4j.Log4jService.reconfigure(Log
> 4jService.java:518)
> at 
> org.apache.geronimo.system.logging.log4j.Log4jService.doStart(Log4jSe
> rvice.java:561)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
> nstance.java:936)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
> (GBeanInstanceState.java:325)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta
> nceState.java:110)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G
> BeanInstanceState.java:132)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI
> nstance.java:537)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi
> cKernel.java:208)
> at 
> org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(
> Configuration.java:315)
> at 
> org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f
> 4b4a9b.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
> Invoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
> n.java:118)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
> java:835)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
> 178)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
> 173)
> at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:286)
> at org.apache.geronimo.system.main.Daemon.(Daemon.java:82)
> at org.apache.geronimo.system.main.Daemon.main(Daemon.java:404)
> log4j:ERROR Ignoring configuration file 
> [file:/C:/geronimo-1.0/var/log/server-lo
> g4j.properties].

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

[jira] Updated: (GERONIMO-3324) Could not scan module for TLD files: illegal char (space)

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3324:
---

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

updated Fixed For field

> Could not scan module for TLD files: illegal char (space)
> -
>
> Key: GERONIMO-3324
> URL: https://issues.apache.org/jira/browse/GERONIMO-3324
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
> Environment: Little-G on WinXP with Java 1.5.0_11
>Reporter: Jens Nicolay
>Assignee: Jarek Gawor
>Priority: Blocker
> Fix For: 2.0.2, 2.1
>
> Attachments: WAR.war
>
>
> 16:25:24,033 ERROR [Deployer] Deployment failed due to 
> org.apache.geronimo.common.DeploymentException: Could not scan module for TLD 
> files: default/WAR/1.0/car Illegal character in path at index 16: 
> WEB-INF/lib/Easy Service.jar
>   at 
> org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.scanModule(JspModuleBuilderExtension.java:298)
>   at 
> org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getTldFiles(JspModuleBuilderExtension.java:236)
>   at 
> org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:179)
>   at 
> org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149)
>   at 
> org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension$$FastClassByCGLIB$$1f60ab3b.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:127)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:828)
>   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.j2ee.deployment.ModuleBuilderExtension$$EnhancerByCGLIB$$cd133fa9.addGBeans()
>   at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:484)
>   at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.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:127)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:828)
>   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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$57321d6a.addGBeans()
>   at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)
>   at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:127)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:828)
>   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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$57321d6a.addGBeans()
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:616)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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(GBeanOperat

[jira] Updated: (GERONIMO-2851) LDAP view in the console

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-2851:
---

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

updated Fixed For field

> LDAP view in the console
> 
>
> Key: GERONIMO-2851
> URL: https://issues.apache.org/jira/browse/GERONIMO-2851
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
> Fix For: 2.0.2, 2.1
>
>
> It looks like the LDAP viewer in the console is ignoring the custom 
> connection information i specified in the 'connect info' panel.

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

[jira] Updated: (GERONIMO-3317) "has not been enhanced" error when invoking an EJB 2.1 Entity Bean

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3317:
---

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

updated Fixed For field

> "has not been enhanced" error when invoking an EJB 2.1 Entity Bean
> --
>
> Key: GERONIMO-3317
> URL: https://issues.apache.org/jira/browse/GERONIMO-3317
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0
>Reporter: Song
>Assignee: Donald Woods
>Priority: Critical
> Fix For: 2.0.2, 2.1
>
> Attachments: GERONIMO-3317-1.patch, GERONIMO-3317.patch, 
> gvtlibTable.ddl
>
>
> My application could be deployed successfully. 
> But when launching an Entity Bean, "has not been enhanced" error is thrown:
> 17:07:58,593 ERROR [OpenEJB] The bean instances business method encountered a 
> system exception: The type "class openejb.gvtlibrary.EJBUser" has not been 
> enhanced.
> <1.0.0-SNAPSHOT-SNAPSHOT fatal user error> 
> org.apache.openjpa.persistence.ArgumentException: The type "class 
> openejb.gvtlibrary.EJBUser" has not been enhanced.
> at 
> org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1610)
> at 
> org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1584)
> at 
> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:663)
> at 
> org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:563)
> at 
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:488)
> at 
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:290)
> at 
> org.apache.openjpa.kernel.BrokerImpl.newObjectId(BrokerImpl.java:1089)
> at 
> org.apache.openjpa.kernel.DelegatingBroker.newObjectId(DelegatingBroker.java:257)
> at 
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:348)
> at 
> org.apache.geronimo.persistence.CMPEntityManagerTxScoped.find(CMPEntityManagerTxScoped.java:125)
> at 
> org.apache.openejb.core.cmp.jpa.JpaCmpEngine.loadBean(JpaCmpEngine.java:171)
> at 
> org.apache.openejb.core.cmp.CmpContainer.findByPrimaryKey(CmpContainer.java:687)
> at 
> org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java:284)
> at 
> org.apache.openejb.core.entity.EntityEjbHomeHandler.findX(EntityEjbHomeHandler.java:57)
> at 
> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:160)
> at 
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:230)
> at 
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> at $Proxy51.findByPrimaryKey(Unknown Source)
> at javaUtility.EjbUtility.getUser(EjbUtility.java:105)
> at servlets.WelcomeServlet.doPost(WelcomeServlet.java:71)
> at servlets.GVTServlet.service(GVTServlet.java:89)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:801)
> org.apache.openejb.InvalidateReferenc

[jira] Updated: (GERONIMO-3374) Admin console uses Generic TranQL RA for non XA driver types

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3374:
---

Affects Version/s: 2.1
Fix Version/s: 2.1

updated Fixed For field

> Admin console uses Generic TranQL RA for non XA driver types
> 
>
> Key: GERONIMO-3374
> URL: https://issues.apache.org/jira/browse/GERONIMO-3374
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0, 2.1
>Reporter: Song
>Assignee: Lin Sun
> Fix For: 2.0.1, 2.1
>
>
> When a non XA database type is selected to create a database pool in admin 
> console, Generic TranQL adapter is used to
> create and deploy the db pool rather than the vendor specific TranQL adapter 
> even for those database(s) for which specifc
> TranQL adapter is present in repository.
> However, with XA drivers, the vendor specific adapter is picked up by the 
> admin console while deploying the database
> plan.

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

[jira] Updated: (GERONIMO-3329) javaVirtualMachine param for StartServerMojo in geronimo-maven-plugin doesn't work

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3329:
---

Fix Version/s: (was: 2.0)
   2.0.2

update Fixed For field

> javaVirtualMachine param for StartServerMojo in geronimo-maven-plugin doesn't 
> work
> --
>
> Key: GERONIMO-3329
> URL: https://issues.apache.org/jira/browse/GERONIMO-3329
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: geronimo-maven-plugin
>Affects Versions: 2.0.x
> Environment: WinXP, Sun 1.5.0_11 and IBM 1.5.0 SR5
>Reporter: Donald Woods
>Assignee: Jason Dillon
> Fix For: 2.0.2, 2.1
>
>
> Was trying to use the javaVirtualMachine param on the geronimo-maven-plugin 
> to specify which JVM to use when starting the server, but the param is 
> ignored.  I tried updating the plugin to take a String called javaHome, but 
> this was never passed in either when it was set in the configuration section 
> of pom.xml.

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

[jira] Updated: (GERONIMO-3380) Derby embedded database pool created from console doesn't work

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3380:
---

Affects Version/s: 2.0.x
Fix Version/s: 2.0.2

updated Fixed For field, as the fixes were also included in 2.0.2

> Derby embedded database pool created from console doesn't work
> --
>
> Key: GERONIMO-3380
> URL: https://issues.apache.org/jira/browse/GERONIMO-3380
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0.x, 2.1
>Reporter: Shiva Kumar H R
>Assignee: David Jencks
>Priority: Critical
> Fix For: 2.0.2, 2.1
>
> Attachments: BankDB.sql, BankDBPool2.xml, geronimo-web.xml, 
> geronimo-web2.xml, WebAppJDBCAccess.war
>
>
> Steps to reproduce:
> 1) From Admin Console's "DB Manager" portlet create a database by name 
> "BankDB" and populate it with the contents of "BankDB.sql". 
> 2) From "Database Pools" portlet, create a new database pool using the 
> Geronimo database pool wizard, with the below information:
> Name of Database Pool: BankDBPool
> Database Type: Derby embedded
> Driver JAR: org.apache.derby/derby/10.2.2.0/jar
> Database: BankDB
> 3) From "Deploy New" portlet, deploy "WebAppJDBCAccess.war" using 
> "geronimo-web.xml".
> 4) Open http://localhost:8080/WebAppJDBCAccess/ and click on "Click here to 
> list Customers". Server will fail to show database contents by throwing 
> following errors at command prompt:
> 19:10:59,555 ERROR [MCFConnectionInterceptor] Error occurred creating 
> ManagedCon
> nection for [EMAIL PROTECTED]
> javax.resource.spi.ResourceAllocationException: Unable to obtain physical 
> connec
> tion to jdbc:derby:BankDB
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDri
> verMCF.java:98)
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.createManagedConnection(JDBCD
> riverMCF.java:73)
> at 
> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCo
> nnection(MCFConnectionInterceptor.java:48)
> at 
> org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterc
> eptor.getConnection(LocalXAResourceInsertionInterceptor.java:41)
> at 
> org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto
> r.internalGetConnection(SinglePoolConnectionInterceptor.java:67)
> at 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn
> terceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
> at 
> org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto
> r.getConnection(TransactionEnlistingInterceptor.java:46)
> at 
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.
> getConnection(TransactionCachingInterceptor.java:96)
> at 
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.ge
> tConnection(ConnectionHandleInterceptor.java:43)
> at 
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(
> TCCLInterceptor.java:39)
> at 
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.
> getConnection(ConnectionTrackingInterceptor.java:66)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allo
> cateConnection(AbstractConnectionManager.java:87)
> at 
> org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56
> )
> at myPackage.ListCustomers.doGet(ListCustomers.java:41)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> bjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:351)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
> at 
> org.apache.catalina.val

[jira] Updated: (GERONIMO-3376) can't customize tomcat's session manager behavior per web context

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3376:
---

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

updated Fixed For field

> can't customize tomcat's session manager behavior per web context
> -
>
> Key: GERONIMO-3376
> URL: https://issues.apache.org/jira/browse/GERONIMO-3376
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.1.1, 2.0
>Reporter: Paul McMahan
>Assignee: Paul McMahan
> Fix For: 2.0.2, 2.1
>
>
> Tomcat allows  session management behavior to be customized per web app 
> context, and geronimo should support this settting in the geronimo-web.xml 
> deployment descriptor.
> However, when you add this to your gbean:
> TomcatManager
>  class="org.apache.geronimo.tomcat.ManagerGBean">
>  name="className">org.apache.catalina.session.StandardManager
> 
> maxActiveSessions=10
> 
> 
> You get an error from cglib when it tries to create the proxy since the 
> ManagerGBean does not provide a  noarg constructor.  Adding the noarg 
> constructor to the gbean fixes this problem and allows session management 
> behavior to be customized per web app context.

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

[jira] Updated: (GERONIMO-3378) Enhance debugability of Deployer by logging errors and more data on debug

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3378:
---

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

updated Fixed For field

> Enhance debugability of Deployer by logging errors and more data on debug
> -
>
> Key: GERONIMO-3378
> URL: https://issues.apache.org/jira/browse/GERONIMO-3378
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0
>Reporter: Ted Kirby
>Assignee: Lin Sun
> Fix For: 2.0.2, 2.1
>
> Attachments: G-3378.patch, G3378-2.patch
>
>
> I spent much effort tracking a configuration problem I had with deployment, 
> and adding these debug statements really helped.
> Also, when deployment throws an exception, especially 
> DeploymentManagerCreationException, I think it should be placed in the 
> deployer log as a FATAL error.

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

[jira] Updated: (GERONIMO-3386) Nothing returned when clicking on "Save" button at creating Tomcat NIO HTTPs Connector

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3386:
---

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

updated Fixed For field

> Nothing returned when clicking on "Save" button at creating Tomcat NIO HTTPs 
> Connector
> --
>
> Key: GERONIMO-3386
> URL: https://issues.apache.org/jira/browse/GERONIMO-3386
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M5
> Environment: Windows xp sp2 x86-32
>Reporter: Song
>Assignee: Paul McMahan
> Fix For: 2.0.2, 2.1
>
>
> When edit a new Tomcat NIO HTTP Connector, modify port from 8081 to 8082, 
> click on "Save" button, No any response returned, and No error or exception 
> is thrown too.

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

[jira] Updated: (GERONIMO-3383) "Connect" button on LDAP Viewer portlet just listens on port "1389" ,not 10389

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3383:
---

  Description: 
Under LDAP portlet, after input Host "localhost",port "10389" and User DN, 
click "Connect"
button, a window pops up prompting: (Note: ApacheDS is running on localhost and 
listening on port 10389)
 
 Error:  Problem  connecting to directory server: localhost:1389
 ** Make sure LDAP Server i srunning and /or connection properties are correct
 
And,The below error can be found in the server.log: 
---
14:48:08,359 WARN  [ExecuteQuery] Method execution failed: 
java.lang.Exception: Problem connecting to directory server: localhost:1389
at 
org.apache.geronimo.console.ldapmanager.LDAPManagerHelper.(LDAPManagerHelper.java:113)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1300)
at uk.ltd.getahead.dwr.create.NewCreator.getInstance(NewCreator.java:59)
at uk.ltd.getahead.dwr.impl.ExecuteQuery.execute(ExecuteQuery.java:181)
at 
uk.ltd.getahead.dwr.impl.DefaultExecProcessor.handle(DefaultExecProcessor.java:48)
at 
uk.ltd.getahead.dwr.impl.DefaultProcessor.handle(DefaultProcessor.java:81)
at 
uk.ltd.getahead.dwr.AbstractDWRServlet.doPost(AbstractDWRServlet.java:162)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.geronimo.console.servlet.ForwardDispatchFilter.doFilter(ForwardDispatchFilter.java:59)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at 
org.apache.geronimo.console.servlet.ContextForwardServlet.doPost(ContextForwardServlet.java:71)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at 
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at 
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
at 
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:801)
14:48:08,359 WARN  [DefaultExecProcessor] Erroring: id[4549_1186469287343] 
[EMAIL PROTECTED]
14:48:16,515 WARN  [ExecuteQuery] Method execution failed: 
java.lang.Exception: Problem connecting to directory server: localhost:1389
at 
org.apache.geronimo.console.ldapmanager.LDAPManagerHelper.(LDAPManagerHelper.java:113)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1300)
at uk.ltd.getahead.dwr.create.NewCreator.getInstance(NewCreator.java:59)
at uk.ltd.getahead.dwr.impl.ExecuteQuery.execute(Exec

[jira] Updated: (GERONIMO-3388) LoginKerberosTest relies on kerberos not being installed... so it can fail on windows?

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3388:
---

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

> LoginKerberosTest relies on kerberos not being installed... so it can fail on 
> windows?
> --
>
> Key: GERONIMO-3388
> URL: https://issues.apache.org/jira/browse/GERONIMO-3388
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.2, 2.1
>
>
> Duminda Ekanayake commented on the user list that LoginKerberosTest was 
> failing on a windows system.  The surefire report indicated that login had 
> succeeded but the principal count was not what the test expected.  Running 
> the test on my machine goes straight to the "kerberos not installed -- pass" 
> catch block.
> The eventual fix is to run this test with actual kerberos from apacheds, but 
> the immediate fix is to look for the right number of principals.
> Here's the clue that login has succeeded... unlike on a mac:
>   
>  message=3D"server-side subject should have three principals
> expected:<3> but was:<2>">
> junit.framework.AssertionFailedError: server-side subject should have three
> principals expected:&3& but was:&2&
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at org.apache.geronimo.security.jaas.LoginKerberosTest.testLogin(
> LoginKerberosTest.java:94)
> 
> Debug is  true storeKey false useTicketCache true useKeyTab
> false doNotPrompt true ticketCache is null isInitiator true KeyTab is null
> refreshKrb5Config is false principal is null tryFirstPass is false
> useFirstPass is false storePass is false clearPass is false
> Acquire TGT from Cache
> Principal is [EMAIL PROTECTED]
> Commit Succeeded
> 
>   

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

[jira] Updated: (GERONIMO-3388) LoginKerberosTest relies on kerberos not being installed... so it can fail on windows?

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3388:
---

Fix Version/s: (was: 2.0.1)
   2.0.2

updated Fixed For field

> LoginKerberosTest relies on kerberos not being installed... so it can fail on 
> windows?
> --
>
> Key: GERONIMO-3388
> URL: https://issues.apache.org/jira/browse/GERONIMO-3388
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.2, 2.1
>
>
> Duminda Ekanayake commented on the user list that LoginKerberosTest was 
> failing on a windows system.  The surefire report indicated that login had 
> succeeded but the principal count was not what the test expected.  Running 
> the test on my machine goes straight to the "kerberos not installed -- pass" 
> catch block.
> The eventual fix is to run this test with actual kerberos from apacheds, but 
> the immediate fix is to look for the right number of principals.
> Here's the clue that login has succeeded... unlike on a mac:
>   
>  message=3D"server-side subject should have three principals
> expected:<3> but was:<2>">
> junit.framework.AssertionFailedError: server-side subject should have three
> principals expected:&3& but was:&2&
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at org.apache.geronimo.security.jaas.LoginKerberosTest.testLogin(
> LoginKerberosTest.java:94)
> 
> Debug is  true storeKey false useTicketCache true useKeyTab
> false doNotPrompt true ticketCache is null isInitiator true KeyTab is null
> refreshKrb5Config is false principal is null tryFirstPass is false
> useFirstPass is false storePass is false clearPass is false
> Acquire TGT from Cache
> Principal is [EMAIL PROTECTED]
> Commit Succeeded
> 
>   

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

[jira] Updated: (GERONIMO-3390) Server Logs portlet - Web Access Log Viewer is broken

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3390:
---

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

updated Fixed For field

> Server Logs portlet -  Web Access Log Viewer is broken
> --
>
> Key: GERONIMO-3390
> URL: https://issues.apache.org/jira/browse/GERONIMO-3390
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0
> Environment: G 2.0 Tomcat
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: 2.0.2, 2.1
>
>
> Web Access Log Viewer is broken.  When "Ignore Dates" is checked, everything 
> except "Max Results" is ignored!!

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

[jira] Updated: (GERONIMO-3400) Log4JService Env and JVM info is no longer being logged

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3400:
---

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

Updated Fixed For field

> Log4JService Env and JVM info is no longer being logged
> ---
>
> Key: GERONIMO-3400
> URL: https://issues.apache.org/jira/browse/GERONIMO-3400
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Logging
>Affects Versions: 2.0, 2.0.x, 2.1
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.0.1, 2.1
>
>
> When the log4j.rootLogger was switched to ERROR instead of INFO, we lost the 
> server startup logging in Log4JService that logs some useful environment and 
> Java information.

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

[jira] Updated: (GERONIMO-3391) Use the config-substitutions.properties for the Deployer remoteDeployAddress settings

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3391:
---

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

Updated Fixed For field

> Use the config-substitutions.properties for the Deployer remoteDeployAddress 
> settings
> -
>
> Key: GERONIMO-3391
> URL: https://issues.apache.org/jira/browse/GERONIMO-3391
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Trivial
> Fix For: 2.0.2, 2.1
>
>
> By using the config-substitutions, if someone changes the base HTTP port, the 
> deployer will be automatically updated.
> Also, makes it a lot easier to setup multiple server instances and to 
> customize the IP Address that the RemoteDeployer will listen on.

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

[jira] Updated: (GERONIMO-3421) ClassFinder classloader problems cause deployer to hang

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3421:
---

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

Added Fixed For 2.0.2, so we can generate a correct list of fixed JIRAs for 
2.0.2

> ClassFinder classloader problems cause deployer to hang
> ---
>
> Key: GERONIMO-3421
> URL: https://issues.apache.org/jira/browse/GERONIMO-3421
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0.x
> Environment: Java(TM) 2 Runtime Environment, Standard Edition (build 
> 1.5.0_12-b04)
> CentOS release 5 (Final)
>Reporter: toby cabot
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.0.2, 2.1
>
> Attachments: deployer-message-patch.txt
>
>
> I build an ear file (containing a rar and a war) with a bug and tried to 
> deploy it.  The deployer printed this stack trace to the console and then 
> hung:
> Exception in thread "Thread-6" java.lang.NoClassDefFoundError: 
> org/jdom/JDOMException
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
> at java.lang.Class.getDeclaredMethods(Class.java:1763)
> at org.apache.xbean.finder.ClassFinder.(ClassFinder.java:162)
> at 
> org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:796)
> at 
> org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:813)
> at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:337)
> at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$35300f85.addGBeans()
> at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)
> at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$35300f85.addGBeans()
> at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:628)
> at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$6c5d899a.buildConfiguration()
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:304)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:126)
> at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
> at net.sf.cgli

[jira] Updated: (GERONIMO-3405) Generating WSDL files are runtime leaves files in use on Windows

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3405:
---

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

Updated Fixed For field

> Generating WSDL files are runtime leaves files in use on Windows
> 
>
> Key: GERONIMO-3405
> URL: https://issues.apache.org/jira/browse/GERONIMO-3405
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.0, 2.1
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
> Fix For: 2.0.2, 2.1
>
>
> When a web service is deployed without wsdl, a wsdl file is generated at 
> runtime using the Sun wsgen tool. The tool leaves some .jar files in use on 
> Windows and therefore when the module is undeployed not all the files are 
> removed. That prevents the module to be re-deployed without restarting the 
> server and removing the old files by hand.
> The easiest work-around for this problem is to fork the wsgen tool on Windows 
> platforms.
>  

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

[jira] Updated: (GERONIMO-3420) Remote deploy of an EAR without an application.xml plan fails

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3420:
---

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

Added Fixed For 2.0.2, so we can generate a correct list of fixed JIRAs for 
2.0.2.

> Remote deploy of an EAR without an application.xml plan fails
> -
>
> Key: GERONIMO-3420
> URL: https://issues.apache.org/jira/browse/GERONIMO-3420
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0, 2.0.x, 2.1
> Environment: Two Linux boxes on the same subnet with 
> remoteDeployAddress reconfigured from localhost to the external interface
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Critical
> Fix For: 2.0.2, 2.1
>
>
> Remote deploy of an EAR that doesn't have a application.xml fails, because 
> the EARConfigBuilder.getEarPlan() is looking for the module/earFile to end 
> with ".ear" to determine if it is an EAR w/o an app plan, but when using the 
> remoteDeployer, the files are created as temp files without an extension, 
> like remote-deploy31452 -
> private ApplicationInfo getEarPlan(File planFile, JarFile earFile, 
> ModuleIDBuilder idBuilder) throws DeploymentException {
> String specDD;
> ApplicationType application = null;
> if (earFile != null) {
> try {
> URL applicationXmlUrl = DeploymentUtil.createJarURL(earFile, 
> "META-INF/application.xml");
> specDD = DeploymentUtil.readAll(applicationXmlUrl);
> //we found something called application.xml in the right 
> place, if we can't parse it it's an error
> XmlObject xmlObject = XmlBeansUtil.parse(specDD);
> application = 
> convertToApplicationSchema(xmlObject).getApplication();
> } catch (XmlException e) {
> throw new DeploymentException("Could not parse 
> application.xml", e);
> } catch (Exception e) {
> //ee5 spec allows optional application.xml, continue with 
> application == null
> if (!earFile.getName().endsWith(".ear")) {
> return null;
> }
> //TODO return application.xml that we can make metadata 
> complete?
> }
> }

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

[jira] Updated: (GERONIMO-3437) Axis2: serviceimplClass being null caused NPE at invoke in JavaBeanDispatcher

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3437:
---

Affects Version/s: 2.0.x
Fix Version/s: 2.0.2

Added Fixed For 2.0.2, so we can generate a correct list of fixed JIRAs for 
2.0.2.

> Axis2:  serviceimplClass being null caused NPE at invoke in 
> JavaBeanDispatcher 
> ---
>
> Key: GERONIMO-3437
> URL: https://issues.apache.org/jira/browse/GERONIMO-3437
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.0.x, 2.1
>Reporter: Lin Sun
>Assignee: Lin Sun
> Fix For: 2.0.2, 2.1
>
>
> I am seeing a NPE from Axis2, and it turned out that we passed 
> serviceimplClass null to Axis2.   

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

[jira] Updated: (GERONIMO-3452) Stateless Session EJBs cannot contain a remove() method

[Donald Woods (JIRA)]

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

Donald Woods updated GERONIMO-3452:
---

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

Manu, can you set this to resolved or close it, since the fix went into OpenEJB?


> Stateless Session EJBs cannot contain a remove() method
> ---
>
> Key: GERONIMO-3452
> URL: https://issues.apache.org/jira/browse/GERONIMO-3452
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0.x, 2.1
> Environment: Windows XP SP2
>Reporter: Aman Nanner
> Fix For: 2.0.2, 2.1
>
>
> We have a stateless session bean that contains a "remove(...)" method that 
> takes in a specific type of array as a parameter.  It seems that the 
> EJBObjectProxyHandler confuses this custom business method with the Entity 
> Bean "remove(...)" method.  Once the logic sees that a method called "remove" 
> is being called, it assumes that it is a "special" method instead of a 
> business method.  Here is a stack trace up to the point where this piece of 
> logic occurs:
> {panel}
> Thread [http-80-3] (Suspended)
>   StatelessEjbObjectHandler(EjbObjectProxyHandler)._invoke(Object, Class, 
> Method, Object[]) line: 62  
>   StatelessEjbObjectHandler(BaseEjbProxyHandler).invoke(Object, Method, 
> Object[]) line: 320   
>   Jdk13InvocationHandler.invoke(Object, Method, Object[]) line: 49
>   $Proxy173.remove(FcModelKey[]) line: not available  
>   FCRemoveTest.test() line: 75
>   
> {panel}
> The following code in the EjbObjectProxyHandler looks up the name of the 
> method from the dispatch table and sees that it is a "special" method name.  
> However, this really only applies to Entity beans and not Session Beans.  
> Therefore, case 4 is executed, and the StatelessEjbObjectHandler.remove(...) 
> method is called, which is empty and only returns null.
> {code}
> Integer operation = (Integer) dispatchTable.get(m.getName());
> if (operation == null) {
> retValue = businessMethod(interfce, m, a, p);
> } else {
> switch (operation.intValue()) {
> case 1:
> retValue = getHandle(m, a, p);
> break;
> case 2:
> retValue = getPrimaryKey(m, a, p);
> break;
> case 3:
> retValue = isIdentical(m, a, p);
> break;
> case 4:
> retValue = remove(interfce, m, a, p);
> break;
> case 5:
> retValue = getEJBHome(m, a, p);
> break;
> case 6:
> retValue = getEJBLocalHome(m, a, p);
> break;
> default:
> throw new RuntimeException("Inconsistent internal 
> state");
> }
> }
> return retValue;
> {code}
> We have not run into this problem with JBoss and Weblogic.  I do not believe 
> having a method called "remove" on a Stateless Session bean is in violation 
> of any spec, so this should work.

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

Re: Can someone push a 3.0-beta-1 snapshot of openejb-core?

[Jacek Laskowski]

On 9/25/07, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:

> > Wait. Why is 2.0.2-SNAPSHOT dependent on 3.0-beta-1?!
>
>  https://issues.apache.org/jira/browse/GERONIMO-3484

Well, I think it should be fixed with using the recent openejb 3.0.0-SNAPSHOT.

Jacek

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

Re: svn commit: r577890 - in /geronimo/server: branches/2.0/modules/geronimo-deployment/src/main/java/org/apache/geronimo/deployment/xmlbeans/ branches/2.0/modules/geronimo-j2ee-schema/src/test/resour

[Jarek Gawor]

Vamsi,

In general I think we agree on how things should be handled when
schema changes. Also, the patch I looked at had schema changes made in
the existing .xsd files and I assumed that the new files would be
introduced in trunk only. But since nobody else has an issue with that
change, that's fine. We just have to remember to publish the new
schemas on the website and (eventually) update the eclipse plugin.

Jarek

On 9/21/07, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
> From "... I can live with introducing an optional element to an existing
> schema" in your original e-mail, I assume that you are not totally against
> the schema changes.  From what I understand, when a schema is changed
> (except for some corrections in comments or some annotations), it can no
> longer have the same version.  Others please correct me if my understanding
> is wrong.  Also, before I started working on this issue, I have raised a
> concern that the schema change may come in the way of the issue getting
> fixed in 2.0.2.  But then the priority seemed to be not to break backward
> compatibility of plugins which turned out to be no priority at all the as
> the few plugins that we may want to preserve backward compatibility won't
> run on G 2.0.1.  To not come in the way of backward compatibility, I
> proposed a patch for branches\2.0 that did not change any interfaces.  But
> then some other changes (for e.g. Holder class) have already broken
> deserialization of config.ser's from G 2.0.1 in G 2.0.2.  I have even given
> 72 hours,  before committing the final patches, for anyone to raise any
> concerns they have in the fix going into branches\2.0.
>
> About what should go into a patch/minor release, I guess it is not
> restricted to bug fixes alone.
>
> Vamsi
>
>
> On 9/21/07, Jarek Gawor < [EMAIL PROTECTED]> wrote:
> > I meant the geronimo-jetty-2.0.1.xsd, geronimo-web-2.0.1.xsd , and
> > geronimo-tomcat-2.0.1.xsd.
> >
> > I guess the main question is what is our versioning policy (if any)
> > and what should and should not go into a patch and/or minor release.
> >
> > Jarek
> >
> > On 9/21/07, Vamsavardhana Reddy < [EMAIL PROTECTED]> wrote:
> > >
> > >
> > > On 9/21/07, Jarek Gawor < [EMAIL PROTECTED]> wrote:
> > > > I'm not sure about these changes. Personally, I'm against any schema
> > > > changes in branches/2.0 but I can live with introducing an optional
> > > > element to an existing schema. However, introducing yet another schema
> > > > in branches/2.0 seems wrong to me.
> > >
> > > I am not sure what this "yet another schema" is referring to.
> > >
> > > > Also, in trunk I would change the namespace to 2.1 (or something like
> > > > that) as we might make even more changes to the schema before we
> > > > release.
> > >
> > > IIUC changing the namespace in trunk should happen if there are more
> changes
> > > to these schemas post 2.0.2 release.  Please correct me if I am wrong.
> > >
> > >
> > > > Jarek
> > > >
> > >
> >
>
>

Re: Interceptors like functionality

[Guillaume Nodet]

On 9/25/07, Przemyslaw Budzik <[EMAIL PROTECTED]> wrote:
>
>
>
> gnodet wrote:
> >
> > But this kind of feature can not easily be generic.  It would be
> > specific for each kind of endpoints I suppose.  Just to understand
> > your use case a bit more, what do you want to do with messages that
> > you don't want to process ? Just discard them ? Then you could use a
> > filter (and use the route transformation layer i've just talked about
> > maybe) or even use a camel filter which is really easy to set up.
> > Also note that in the OSGi way, the whole classloader architecture is
> > different and you can easily share libraries between JBI applications
> > (you're not limited anymore to jars included in the SU).  Even with
> > 3.2, you can already add a SL to a SU classloader.
> >
> >
>
> Around intercepting is useful when eg. measuring because it wraps
> invocation.

Agreed.

> Listeners are not good for me because of their scope. Once set
> per container collect all events from all assemblies. I want to aspectize
> given SU/SA only.

So it should be easier to do that in servicemix 4.0, as everything
will be contained in a single jar.  This is just a matter of defining
the right filter (and easily).  You could already do that, but there
is no easy way to identify the SU/SA, so you'd end up with listing all
the possible endpoints.  Still, this is currently doable.

>  ExchangeListener has exchangeSent()
> so it is like "after". Still a limitation. I know that there is an option to
> use SL or copy jars to lib/optional, but it is still intrusive. Using
> spring+aspectj AOP is powerful but what I need is only apply before/after
> interceptor to given SU with less possible effort. I do believe there could
> be sort of generic solution.

The problem with exchange interception at the endpoint level is that
you may want to intercept exchanges sent by this endpoint, which is
not possible using AOP.  However as the exchange listener will receive
all sent and received message, it can easily filter what you need.

For example you could define:


   
   


We need to have better support for endpoint filtering, but once we
have this, it should be quite easy to add your interceptors and easily
control the exchanges you receive.
And this would just use wrap the provided ExchangeListener with a
wrapping implementation using the define filtering.   Makes sense ?

> --
> View this message in context: 
> http://www.nabble.com/Interceptors-like-functionality-tf4515215s12049.html#a12882271
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
>


-- 
Cheers,
Guillaume Nodet

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

[jira] Commented: (GERONIMO-3481) Offline deployer throws BIND Exception when port 1099 is in use

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy commented on GERONIMO-3481:
---

GERONIMO-3484 is resolved.  But then axis2-deployer is starting openejb :(.

> Offline deployer throws BIND Exception when port 1099 is in use
> ---
>
> Key: GERONIMO-3481
> URL: https://issues.apache.org/jira/browse/GERONIMO-3481
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0.1, 2.0.x, 2.1
> Environment: G 2.0.1 - Running multiple instances
>Reporter: Vamsavardhana Reddy
>Assignee: David Jencks
> Fix For: 2.0.2, 2.0.x, 2.1
>
> Attachments: GERONIMO-3481-1.patch, GERONIMO-3481-2.patch, 
> GERONIMO-3481-2a.patch, GERONIMO-3481-3.patch, GERONIMO-3481-weird.patch
>
>
> Offline deployer throws Bind Exception when port 1099 is in use.  Here is a 
> scenario steps in which the problem is experienced.
> 1.  Extract G-2.0.1-Tomcat distro to C:\
> 2.  Create a dir "myserver" under C:\geronimo-j2ee-tomcat-2.0.1 and copy 
> C:\geronimo-j2ee-tomcat-2.0.1\var to 
> C:\geronimo-j2ee-tomcat-2.0.1\myserver\var (all sub-directories).
> 3.  Edit 
> C:\geronimo-j2ee-tomcat-2.0.1\myserver\var\config-substitutions.properties to 
> set PortOffset=10.
> 4.  Open a command window and start Geronimo.  Since 
> org.apache.geronimo.server.name is not set, this will start the default 
> server instance.
> 5.  Open a second command window, set 
> GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=myserver.  This will be 
> command window to run the second server instance with name "myserver"
> 6.  Run deploy.bat --offline list-modules.
> At step 6, I am getting a BIND Exception since port 1099 is in use (by the 
> default server instance) and the offline deployer is attempting to start rmi 
> naming on port 1099.  Since, this deploy command is run against second server 
> instance, I would expect that it uses the configuration properties of 
> "myserver" in which case it should use port 1109 to start rmi-naming if at 
> all there is a need.  When port 1099 is not in use, the offline deployer 
> works as expected by updating proper config.xml file when a configuration is 
> deployed/undeployed.

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

Re: MEJB Question

[Kevan Miller]

On Sep 24, 2007, at 3:03 PM, David Jencks wrote:



On Sep 20, 2007, at 8:56 AM, Anita Kulshreshtha wrote:

   I am leaning towards deploying MEJB as an EJBModule. To auto  
deploy

this I will be adding an mejb config. Are there any objections?


no :-)

I've been wondering if we should try to separate mejb security from  
other security somehow and thought perhaps we should use a  
GeronimoGroupPrincipal named mejb or mejb-admin.  I think this  
would make it easier to e.g. give someone access to the web console  
but not the mejb or vice-versa.  If we wanted to be even fancier we  
could try mejb-read and mejb-write.


Would this improve modularity or just create more difficult  
configuration?


I'm not sure about improving "modularity", but it seems useful. I'd  
definitely advocate an mejb-specific group. Separation of read/write  
selectivity seems less important and, I would assume, harder to do...


--kevan 
 

Re: [DISCUSS] G 2.0.2 Release plan

[Kevan Miller]

On Sep 25, 2007, at 8:51 AM, David Jencks wrote:


I've committed to branches/2.0 also.


Thanks David!

I think this leaves us with:

* integration of the MEJB code itself
* release of OpenEJB 3.0-Beta

One thing I've noticed -- the default JNDI name for EJB's has been  
changed in OpenEJB. So, there is a compatibility issue with 2.0.1. We  
might be able to configure how OpenEJB generates this default to  
maintain backward compatibility. Better, IMO, to go ahead and match  
OpenEJB's behavior.


--kevan 

Re: Can someone push a 3.0-beta-1 snapshot of openejb-core?

[Vamsavardhana Reddy]

On 9/25/07, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
>
> On 9/25/07, David Jencks <[EMAIL PROTECTED]> wrote:
> > I just tried and it tried to install into my local maven repo
> > (?!?!?!) and I have to go get on a plane.  Until this is straightened
> > out building g. 2.0.2-SNAPSHOT will require building openejb locally
> > first.
>
> Wait. Why is 2.0.2-SNAPSHOT dependent on 3.0-beta-1?!


https://issues.apache.org/jira/browse/GERONIMO-3484


I don't seem to
> remember it's been published.
>
> Have a nice flight! ;-)
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>

Re: MEJB Question

[Anita Kulshreshtha]

--- David Jencks <[EMAIL PROTECTED]> wrote:

> 
> On Sep 20, 2007, at 8:56 AM, Anita Kulshreshtha wrote:
> 
> >I am leaning towards deploying MEJB as an EJBModule. To auto
> deploy
> > this I will be adding an mejb config. Are there any objections?
> 
> no :-)
> 
> I've been wondering if we should try to separate mejb security from  
> other security somehow and thought perhaps we should use a  
> GeronimoGroupPrincipal named mejb or mejb-admin.  I think this would 
> 
> make it easier to e.g. give someone access to the web console but not
>  
> the mejb or vice-versa.  If we wanted to be even fancier we could try
>  
> mejb-read and mejb-write.

This is a good idea. MEJB will have two roles: mejbuser (read only)
and mejbadmin (read write). One option is to map mejbuser to admin and
mejbadmin to mejb-admin. The 'admin' already has access to most of the
info via jmx. For the sake of simplicity we could still ship with only
"admin" group and require that mejb-admin be created to get write
access to mejb.
  Should we restric access to JMXViewer also? 
  
> 
> Would this improve modularity or just create more difficult  
> configuration?

   Right now I am stuck at this:
   @RolesAllowed({a, b})
   public class . {
   @RolesAllowed(b) {
   public .. dosomething() {
   }
   }
   Does this prevent 'a' from accessing dosomething()? 

Thanks
Anita
   
> 
> thanks
> david jencks
> 
> >
> > Thanks
> > Anita
> >
> > --- Anita Kulshreshtha <[EMAIL PROTECTED]> wrote:
> >
> >> Is there a reason for not deploying MEJB as an application and
> >> hard
> >> coding it in g-openejb?
> >>
> >> Thanks
> >> Anita
> >>
> >>
> >>
> >>
> >>
> >
>
__
> 
> > __
> >> Be a better Heartthrob. Get better relationship answers from
> someone
> >> who knows. Yahoo! Answers - Check it out.
> >> http://answers.yahoo.com/dir/?link=list&sid=396545433
> >>
> >
> >
> >
> >
> >
>
__
> 
> > __
> > Luggage? GPS? Comic books?
> > Check out fitting gifts for grads at Yahoo! Search
> >
>
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
> 
> 



   

Looking for a deal? Find great prices on flights and hotels with Yahoo! 
FareChase.
http://farechase.yahoo.com/

Re: integration testing in spring

[Guillaume Nodet]

It would be nice to use that and do some functional test / load
testing using the soap ui maven plugin too...

On 9/25/07, James Strachan <[EMAIL PROTECTED]> wrote:
> I've taken a first stab at adding an easy way of integration testing
> JBI artifacts (shared libraries, components and service assemblies)
> using a simple Spring XML notation that can be included into any JUnit
> test case...
>
> http://cwiki.apache.org/SM/integration-testing-in-spring.html
>
> This allows you to depend on artifacts using their maven groupId and
> artifactId and then the version is inferred (using the generated
> META-INF/maven/dependencies.properties via the jbi-maven-plugin).
>
> My idea was to show how we can boot up servicemix with some artifacts
> from the local repo, then use Camel to fire in messages and make
> assertions and so forth to test that the JBI artifacts actually deploy
> correctly and do what is expected etc.
>
> Feedback most appreciated if this can be improved...
>
> --
> James
> ---
> http://macstrac.blogspot.com/
>
> Open Source SOA
> http://open.iona.com
>


-- 
Cheers,
Guillaume Nodet

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

Re: Problems with service mix dependencies using maven

[Daniel Kulp]

Actually, within 4 hours of upload, it should be at central and within a 
day from there, out to all the mirrors.Thus, you shouldn't need to 
add anything to the poms now.Yea!!

Dan


On Tuesday 25 September 2007, Freeman Fang wrote:
> Hi,
>
> Since srevicemic 3.1.2 is released after graduate, so now you should
> find 3.1.2 artifacts from
> http://people.apache.org/repo/m2-ibiblio-rsync-repository
> Would you please add this url to your maven settings.xml, this should
> resolve your build problem.
>
> Best Regards
> Freeman
>
> Eduardo de Vera wrote:
> > Hello,
> >
> > First of all congratulations for being graduated as a top level
> > proyecto at
> > the ASF. It's was about time considering all the efforts the whole
> > group has
> > done for this piece of fine work.
> >
> > I dont know if I should post a jira about this issue I found
> > following the Apache Servicemix Tutorial. I have a problem with the
> > maven dependencies that belong to the tutorial application. I dont
> > know if this is due to a Maven bug or a problem with the pom files.
> >
> > The error I am getting when I try to build the service assembly is:
> >
> > [INFO] Scanning for projects...
> > [INFO] Reactor build order:
> > [INFO]   Tutorial
> > [INFO]   Tutorial :: File SU
> > [INFO]   Tutorial :: SA
> > [INFO]
> > 
> > [INFO] Building Tutorial
> > [INFO]task-segment: [install]
> > [INFO]
> > 
> > [INFO] [site:attach-descriptor]
> > [INFO] [install:install]
> > [INFO] Installing
> > /Users/edevera/Documents/desarrollo/servicemix-tutorial-1/parent/pom
> >.xml to
> > /Users/edevera/.m2/repository/org/apache/servicemix/tutorial/parent/
> >1.0-SNAPSHOT/parent- 1.0-SNAPSHOT.pom
> > [INFO]
> > 
> > [INFO] Building Tutorial :: File SU
> > [INFO]task-segment: [install]
> > [INFO]
> > 
> > [INFO] [resources:resources]
> > [INFO] Using default encoding to copy filtered resources.
> > Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/wss4j/wss4j/1
> >.5.0/wss4j-1.5.0.pom Downloading:
> > http://repository.jboss.com/maven2//wss4j/wss4j/1.5.0/wss4j-1.5.0.po
> >m Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/wss4j/wss4j/1
> >.5.0/wss4j-1.5.0.pom Downloading:
> > http://repo1.maven.org/maven2/wss4j/wss4j/1.5.0/wss4j-1.5.0.pom
> > Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/org/opensaml/
> >opensaml/1.1/opensaml-1.1.pom Downloading:
> > http://repository.jboss.com/maven2//org/opensaml/opensaml/1.1/opensa
> >ml-1.1.pom Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/org/opensaml/
> >opensaml/1.1/opensaml-1.1.pom Downloading:
> > http://repo1.maven.org/maven2/org/opensaml/opensaml/1.1/opensaml-1.1
> >.pom Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/xml-security/
> >xmlsec/1.3.0/xmlsec-1.3.0.pom Downloading:
> > http://repository.jboss.com/maven2//xml-security/xmlsec/1.3.0/xmlsec
> >-1.3.0.pom Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/xml-security/
> >xmlsec/1.3.0/xmlsec-1.3.0.pom Downloading:
> > http://repo1.maven.org/maven2/xml-security/xmlsec/1.3.0/xmlsec-1.3.0
> >.pom Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/org/apache/se
> >rvicemix/servicemix-common/3.1.2/servicemix-common-3.1.2.jar
> > Downloading:
> > http://repository.jboss.com/maven2//org/apache/servicemix/servicemix
> >-common/3.1.2/servicemix-common-3.1.2.jar Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/org/apache/se
> >rvicemix/servicemix-common/3.1.2/servicemix-common-3.1.2.jar
> > Downloading:
> > http://www.ibiblio.org/maven2/org/apache/servicemix/servicemix-commo
> >n/3.1.2/servicemix-common-3.1.2.jar Downloading:
> > http://svn.apache.org/repos/asf/incubator/servicemix/m2-repo/org/apa
> >che/servicemix/servicemix-common/3.1.2/servicemix-common-3.1.2.jar
> > Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/org/apache/se
> >rvicemix/servicemix-shared/3.1.2/servicemix-shared-3.1.2.jar
> > Downloading:
> > http://repository.jboss.com/maven2//org/apache/servicemix/servicemix
> >-shared/3.1.2/servicemix-shared-3.1.2.jar Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/org/apache/se
> >rvicemix/servicemix-shared/3.1.2/servicemix-shared-3.1.2.jar
> > Downloading:
> > http://www.ibiblio.org/maven2/org/apache/servicemix/servicemix-share
> >d/3.1.2/servicemix-shared-3.1.2.jar Downloading:
> > http://svn.apache.org/repos/asf/incubator/servicemix/m2-repo/org/apa
> >che/servicemix/servicemix-shared/3.1.2/servicemix-shared-3.1.2.jar
> > Downloading:
> > http://people.apache.org/repo/m2-incubating-repository/org/apache/se
> >rv

Re: Interceptors like functionality

[Przemyslaw Budzik]

gnodet wrote:
> 
> But this kind of feature can not easily be generic.  It would be
> specific for each kind of endpoints I suppose.  Just to understand
> your use case a bit more, what do you want to do with messages that
> you don't want to process ? Just discard them ? Then you could use a
> filter (and use the route transformation layer i've just talked about
> maybe) or even use a camel filter which is really easy to set up.
> Also note that in the OSGi way, the whole classloader architecture is
> different and you can easily share libraries between JBI applications
> (you're not limited anymore to jars included in the SU).  Even with
> 3.2, you can already add a SL to a SU classloader.
> 
> 

Around intercepting is useful when eg. measuring because it wraps
invocation. Listeners are not good for me because of their scope. Once set
per container collect all events from all assemblies. I want to aspectize
given SU/SA only. ExchangeListener has exchangeSent()
so it is like "after". Still a limitation. I know that there is an option to
use SL or copy jars to lib/optional, but it is still intrusive. Using
spring+aspectj AOP is powerful but what I need is only apply before/after
interceptor to given SU with less possible effort. I do believe there could
be sort of generic solution.
-- 
View this message in context: 
http://www.nabble.com/Interceptors-like-functionality-tf4515215s12049.html#a12882271
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

Re: [VOTE] Release ServiceMix 3.1.2

[Daniel Kulp]

On Tuesday 25 September 2007, Guillaume Nodet wrote:
> I think we should add a section to the release guide with all the
> checks we need to do to verify the release:
>   * artifacts are signed
>   * KEYS file present with key inside
>   * check this bug of the gpg plugin

This one will be gone soon.   I started the vote for the GPG plugin 
yesterday.   Hopefully, by the end of the week, you can update the 
version of GPG you use to 1.0-beta-4 and that issue will go away.

Dan


>   * ...
>
> On 9/24/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> > OK.   New issue (very minor)
> >
> > Due to a bug in the GPG plugin (I have it fixed, am starting a new
> > release shortly), some of your asc files have the wrong name.  
> > Example:
> >
> > http://people.apache.org/~ffang/maven_staging_graduate/org/apache/se
> >rvicemix/samples/loan-broker/loan-broker-lw-su/3.1.2/
> >
> > loan-broker-lw-su-3.1.2-.zip.asc
> > should just be:
> > loan-broker-lw-su-3.1.2.zip.asc
> > Just rename it and you should be all set.
> >
> > Probably a find for "-." should find all of them.
> >
> > Dan
> >
> > On Monday 24 September 2007, Freeman Fang wrote:
> > > Hi Dan,
> > >
> > > You can find my public key from
> > > http://pgp.mit.edu:11371/pks/lookup?search=Freeman+Fang&op=vindex
> > > now, signed by Bo.
> > > Also I put it into KEYS.
> > >
> > > Since I generate new private and public key to sign and deploy it
> > > again, so to verify the signature, you need download the kit and
> > > its .asc again.
> > >
> > > Best Regards
> > >
> > > Freeman
> > >
> > > Daniel Kulp wrote:
> > > > On Friday 21 September 2007, Guillaume Nodet wrote:
> > > >> In theory, the public key should be in the web of trust.
> > > >> See http://people.apache.org/~henkp/trust/
> > > >
> > > > Well, yes.   But I need to see the key first to see if its been
> > > > signed by anyone.   Right now, we cannot even get that far
> > > >
> > > > Freeman: I assume you are sitting pretty close to Bo.  The two
> > > > of you should have a quick "key signing party" and get your keys
> > > > signed. Then get the public key into the public keyservers and
> > > > into the KEYS file.   That would be a start (since Bo's key has
> > > > been signed by other apache folks).
> > > >
> > > > Dan
> > > >
> > > >> On 9/21/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> > > >>> Minor issue:
> > > >>> Your GPG public key is not in the KEYS file.   I also could
> > > >>> not find it in the public keyserver at pgp.mit.edu.   Thus, I
> > > >>> could not verify the signatures.
> > > >>>
> > > >>> Dan
> > > >>>
> > > >>> Freeman Fang wrote:
> > >  Hi All,
> > > 
> > >  I have uploaded a version of ServiceMix 3.1.2 for you to
> > >  review. See
> > >  http://cwiki.apache.org/confluence/display/SM/ServiceMix+3.1.
> > > 2 for all the links and release notes.
> > > 
> > >  [ ] +1 Release ServiceMix 3.1.2
> > >  [ ] ± 0
> > >  [ ] -1 Do not release ServiceMix 3.1.2
> > > 
> > >  Cheers
> > > 
> > >  Freeman
> > > >>>
> > > >>> --
> > > >>> View this message in context:
> > > >>> http://www.nabble.com/-VOTE--Release-ServiceMix-3.1.2-tf449161
> > > >>>7s12
> > > >>>
> > > >>>04 9.html#a12824617 Sent from the ServiceMix - Dev mailing list
> > > >>> archive at Nabble.com.
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727C: 508-380-7194
> > [EMAIL PROTECTED]
> > http://www.dankulp.com/blog



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Re: Anyone want to smoke test tranql adapters?

[Lin Sun]

David, I tried both the local and xa rars for oracle and it works good 
with daytrader (without any issue in G2188).   I have a question on the 
local and xa rars.   Is there any reason why we want to continue 
releasing the local rars?  Seems it is rather confusing to have so many 
rars for a user to select...


Lin

David Jencks wrote:
I made one code change and a whole lot of build cleanup in the tranql 
adapters and I'd like to release them, but I'm not set up to try most of 
them out at all.  Is anyone able to give any of them a try?


We have..

generic
db2
derby
mysql
oracle
postgres

IIUC Matt's going to try to do at least the db2 connectors and maybe 
mysql.  If anyone want to try out one of the others let me know and I'll 
send them to you (or you can build from trunk, although the sequence of 
stuff to build may be a bit hard to figure out)


thanks
david jencks

[jira] Closed: (GERONIMO-3484) openejb-deployer should not require openejb to be running

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy closed GERONIMO-3484.
-

Resolution: Fixed

Changed the dependency scope to runtime.  Revision: 579289

1.  With this change, openejb-deployer does not start openejb configuration any 
more.
2.  GERONIMO-3481 is still not solved coz axis2-deployer is starting the 
openejb config :((

> openejb-deployer should not require openejb to be running
> -
>
> Key: GERONIMO-3484
> URL: https://issues.apache.org/jira/browse/GERONIMO-3484
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0.1
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.2, 2.1
>
>
> The fix for this was worked out under GERONIMO-3481 but the title there isn't 
> clear that this is the cause and there is another proposed change there that 
> should not be mixed up with this change.

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

Re: Interceptors like functionality

[Guillaume Nodet]

But this kind of feature can not easily be generic.  It would be
specific for each kind of endpoints I suppose.  Just to understand
your use case a bit more, what do you want to do with messages that
you don't want to process ? Just discard them ? Then you could use a
filter (and use the route transformation layer i've just talked about
maybe) or even use a camel filter which is really easy to set up.
Also note that in the OSGi way, the whole classloader architecture is
different and you can easily share libraries between JBI applications
(you're not limited anymore to jars included in the SU).  Even with
3.2, you can already add a SL to a SU classloader.

On 9/25/07, Przemyslaw Budzik <[EMAIL PROTECTED]> wrote:
>
>
>
> gnodet wrote:
> >
> >
> > What kind of use case do you have exactly ?
> >
> >
>
> Listeners are not enough I think since it is based only on events. What
> about "around" interceptors and eg. situation when you want to cancel some
> exchange? My case is standard one. We have to proxy eg. jms bc (in fact it
> is marshaller not the endpoint itself) in order to collect some metrics
> (before and after). Every SU has dependencies to aopalliance, spring-aop,
> aspectj, cglib etc. It is too much heavyweight. It seems to be trivial to me
> to have feature like that:
>
> 
>
> or even:
>
> 
>
> where myAdvice is pojo implementing some interface with chain of
> interceptors within eg. Logging+Metrics
>
> interceptor could have method with exchange as parameter. Turning aspects
> on/off would be the
> matter of commenting/uncommenting one attribute in endpoint. The aspect code
> would be very lightweight not dependent to any API at all except eg. one
> interface.
>
>
> --
> View this message in context: 
> http://www.nabble.com/Interceptors-like-functionality-tf4515215s12049.html#a12879640
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
>


-- 
Cheers,
Guillaume Nodet

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

[jira] Reopened: (GERONIMO-3484) openejb-deployer should not require openejb to be running

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy reopened GERONIMO-3484:
---


Does not seem to solve the problem on branches\2.0.  Openejb config is started 
while running the offline deployer (which results in BIND Exception in the 
scenario given in GERONIMO-3481).

> openejb-deployer should not require openejb to be running
> -
>
> Key: GERONIMO-3484
> URL: https://issues.apache.org/jira/browse/GERONIMO-3484
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0.1
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.2, 2.1
>
>
> The fix for this was worked out under GERONIMO-3481 but the title there isn't 
> clear that this is the cause and there is another proposed change there that 
> should not be mixed up with this change.

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

[jira] Closed: (DAYTRADER-54) PingServlet2Include primitive broken

[Christopher James Blythe (JIRA)]

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

Christopher James Blythe closed DAYTRADER-54.
-

   Resolution: Fixed
Fix Version/s: 2.0
   1.2

Fixed

> PingServlet2Include primitive broken
> 
>
> Key: DAYTRADER-54
> URL: https://issues.apache.org/jira/browse/DAYTRADER-54
> Project: DayTrader
>  Issue Type: Bug
>  Components: Web Tier
>Affects Versions: 1.2, 2.0
>Reporter: Christopher James Blythe
>Assignee: Christopher James Blythe
>Priority: Minor
> Fix For: 1.2, 2.0
>
>
> While running through the primitives, found that the PingServlet2Include 
> primitive is broken. Took a look at the web.xml and just need to make some 
> modifications.

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

[jira] Closed: (DAYTRADER-24) Clean up plan files in 1.2 branch

[Christopher James Blythe (JIRA)]

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

Christopher James Blythe closed DAYTRADER-24.
-

Resolution: Fixed

> Clean up plan files in 1.2 branch
> -
>
> Key: DAYTRADER-24
> URL: https://issues.apache.org/jira/browse/DAYTRADER-24
> Project: DayTrader
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Christopher James Blythe
>Assignee: Christopher James Blythe
>Priority: Minor
> Fix For: 1.2, 2.0
>
> Attachments: daytrader-24.1120.patch, daytrader-24.patch
>
>
> The plan files in the 1.2 branch are are based on Geronimo 1.0 and need to be 
> updated (similar to what is in the Daytrader 1.1 branch). It would also be 
> nice if we could add plan files for Oracle and DB2 data sources. However, it 
> looks like we do not include the necessary Tranql rars in Geronimo to support 
> this out of the box.

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