from:"Quintin Beukes"


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

Quintin Beukes commented on GERONIMO-4871:
--

Unless I imagined things, it looks like Geronimo is now capturing stdout/stderr 
and sending it to the geronimo.log instead of geronimo.out. And also depending 
on the output type it prints a progress bar. This wasn't the case in 2.1. I had 
to look at all my System.out.println() statements in geronimo.out, where the 
other day I found they were being sent to geronimo.log after the server 
completed starting.

If this is programmatically, maybe it's related to this. It comes back to my 
previous comment. Maybe it IS doing the thread dump, you just can't find to 
where, or the pipe is broken and it goes into nothingness.

> Something blocking 'kill -3' signals?
> -
>
> Key: GERONIMO-4871
> URL: https://issues.apache.org/jira/browse/GERONIMO-4871
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Kevan Miller
> Fix For: 2.2.1
>
>
> I occasionally use 'kill -3' to cause a java process to dump all thread 
> stacks. For some reason, this isn't working on Geronimo 2.2

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

[jira] Commented: (GERONIMO-4871) Something blocking 'kill -3' signals?


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

Quintin Beukes commented on GERONIMO-4871:
--

One final note.

Perhaps the logging level is configured differently. Try setting the log levels 
to trace on the Geronimo logging and the JRE logging - in fact, on all logging 
frameworks accessible. Maybe somehow it logs to another file somewhere.

I had a look around on google, and it does seem like there are cases where 
people had to change their logging levels in order to see the thread dumps.


> Something blocking 'kill -3' signals?
> -
>
> Key: GERONIMO-4871
> URL: https://issues.apache.org/jira/browse/GERONIMO-4871
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Kevan Miller
> Fix For: 2.2.1
>
>
> I occasionally use 'kill -3' to cause a java process to dump all thread 
> stacks. For some reason, this isn't working on Geronimo 2.2

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

[jira] Commented: (GERONIMO-4871) Something blocking 'kill -3' signals?


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

Quintin Beukes commented on GERONIMO-4871:
--

Check if the -Xrs option is specified perhaps, by echoing the final command 
used to start the JVM. -Xrs disables this.

Further, try adding a shutdown hook and the doing a SIGTERM. Check if the 
shutdown hooks execute, but the thread dump doesn't work, or if neither work.

Q

> Something blocking 'kill -3' signals?
> -
>
> Key: GERONIMO-4871
> URL: https://issues.apache.org/jira/browse/GERONIMO-4871
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Kevan Miller
> Fix For: 2.2.1
>
>
> I occasionally use 'kill -3' to cause a java process to dump all thread 
> stacks. For some reason, this isn't working on Geronimo 2.2

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

[jira] Commented: (GERONIMO-4871) Something blocking 'kill -3' signals?


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

Quintin Beukes commented on GERONIMO-4871:
--

It has to be something that changed between that 2. I'm sure that part is 
obvious for anyone reading this.

It has to also be something the 2 does different. Perhaps related to a 
JavaAgent or JMX? Something else that captures the signal? 

Have you tried echoing the command geronimo.sh uses to start and then running 
it manually, removing arguments until you find on that could possibly trigger 
this? Does the same happen when you run the minimal server? Have you tried to 
remove modules until you could perhaps find one, which without it everything 
works?

If I had a Mac I would have a look at it, but ... :>

> Something blocking 'kill -3' signals?
> -
>
> Key: GERONIMO-4871
> URL: https://issues.apache.org/jira/browse/GERONIMO-4871
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Kevan Miller
> Fix For: 2.2.1
>
>
> I occasionally use 'kill -3' to cause a java process to dump all thread 
> stacks. For some reason, this isn't working on Geronimo 2.2

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

Re: Singletons in Geronimo

2009-10-25 Thread Quintin Beukes

Hey,

Thanks for the analysis. Would be great to not have to rerelease
OpenEJB. I will have a look at doing anything needed to get it running
with the new modifications.

Finally, there is something else in the patches (other than the first
deadlock). When you invoke on a Singleton, itcauses the ReadWriteLock
to fail with a NullPointerException. It's related to the AccessTimeout
option for the SingletonContainer. If it doesn't specify a unit, then
the Duration object parses a null "unit". This causes the Unit object
in SingletonContainer to be set to null. I included in the patch a
check for null, which then causes a default of TimeUnit.SECONDS to be
used.

I think it's a good idea to modify OpenEJB for this in any case.
Unless you guys want a unit specified as a requirement? This might be
a bit counter intuitive, as one is used to simply specifying a number
for a timeout. And as I understand the source code for
Duration.parse(), the unit was made to be optional. So if this was the
intention, such a modification would be needed somewhere in OpenEJB.
OR in the GBean a unit could be "injected" into the timeout value. In
such a case problems could still occur when these values are
configured in a pure OpenEJB environment.

Though to avoid another release at this point, I'll simply add a unit
in Geronimo's config.xml.

So I'll make 2 patch sets. One for Geronimo at the point. And another
for OpenEJB's trunk. Let me know what you guys choose to do regarding
this unit.

Quintin Beukes

On Sat, Oct 24, 2009 at 3:29 AM, David Jencks  wrote:
> I attached a patch to GERONIMO-4918 that mostly reverses the dependencies
> between EjbModuleImpl and EjbDeployment so the deployments will start first.
>  I think this is the main bit needed for David's idea on how to fix this
> without the wait() code in the geronimo wiring.  There are some other
> changes needed before this will work such as removing the lifecycle methods
> from EjbDeployment.  It also annotates EjbModuleImpl and adds wildcard
> support to collection valued references, I may well commit this last bit
> separately.
> thanks
> david jencks
> On Oct 23, 2009, at 5:33 PM, David Blevins wrote:
>
> On Oct 22, 2009, at 1:27 PM, Quintin Beukes wrote:
>
> Unfortunately the only way I could see how to get the @Startup working
>
> was to modify OpenEJB to create a property which gives the
>
> responsibility over to Geronimo, and there the only way was to create
>
> a new GBean which has it's lifecycle doStart() called after all EJBs
>
> are in the RUNNING state.
>
> I couldn't find a better way.
>
> Very impressive that you could find the problem at all as well as a workable
> fix.  That code makes my brain hurt nearly every time I look at it.
>
> I checked in the more generic Singleton code.  Left out the alternate
> startup code -- though it was actually pretty clever.
>
> This chunk of code in GeronimoThreadContextListener was not there when we
> wrote the initial integration, so I went digging around as to why it was
> added (there shouldn't be any locking code in the integration at all, much
> less wait/notify):
>
> At the 10,000 foot view, this chunk of code in GeronimoThreadContextListener
> must die:
>
>    synchronized (deploymentInfo) {
>    if (deploymentInfo.get(EjbDeployment.class) == null) {
>    if (!deploymentInfo.isDestroyed()) {
>    try {
>    deploymentInfo.wait();
>    } catch (InterruptedException e) {
>    log.warn("Wait on deploymentInfo interrupted
> unexpectedly");
>    }
>    }
>    }
>    }
>
> Seems that code was added for GERONIMO-3780 which is essentially the same as
> the Singleton injection/lookup issue.  Both issues boil down to the fact
> that lookups may happen inside the EjbModuleImpl.start() method where ejbs
> are created by OpenEJB.  The wait/notify block works for MDBs as all their
> lookups will happen in other threads and not inside the startup thread.
>  With Singletons this is not the case, so the startup thread ends up waiting
> on its own thread and a deadlock occurs.
>
> Ultimately, this is flawed and the data that is required in
> GeronimoThreadContextListener needs to be made available in some way before
> we call EjbModuleImpl.start().  I talked it over with David Jencks and the
> EjbDeployment objects are available when the EjbModuleImpl gbean is start.
>  Then we should be able to hand them directly to the
> GeronimoThreadContextLister *before* asking OpenEJB to create the EJBs (and
> subsequently do lookups).  When the contextEntered method is called we can
&g

[jira] Updated: (GERONIMO-4928) In the JPA persistence.xml loading code, exclude-unlisted-classes handling not compliant with JPA3.0 spec

2009-10-23 Thread Quintin Beukes (JIRA)


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

Quintin Beukes updated GERONIMO-4928:
-

Description: 
{panel:title=EJB 3.0 JPA spec FR, section 6.2.1.6}
The set of managed persistence classes that are managed by a persistence unit 
is defined by using one or
more of the following:[41]
 • One or more object/relational mapping XML files
 • One or more jar files that will be searched for classes
 • An explicit list of the classes
 • The annotated managed persistence classes contained in the root of the 
persistence unit (unless
 the exclude-unlisted-classes element is specified)
{panel}

{panel:title=further on in the same section}
All classes must be on the classpath to ensure that entity managers from 
different persistence units that
map the same class will be accessing the same identical class.
{panel}

This says that if exclude-unlisted-classes is specified as true, then only the 
classes listed in  elements must be used in the PU. If it is specified 
as false, then the annotated classes must be included. It's the only thing that 
exclude-unlisted-classes affects. It doesn't affect classes from other units, 
and if false it doesn't say that  must be ignored, which is what the 
following code does in PersistenceUnitBuilder.java:

{code:title=PersistenceUnitBuilder.java line 310|borderStyle=solid}
if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
} else {
gbeanData.clearAttribute("managedClassNames");
}
{code}

I removed the else block to leave:
{code:title=PersistenceUnitBuilder.java Patched|borderStyle=solid}
if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
}
{code}

Without this Geronimo isn't JavaEE 5 compliant.


  was:
According to the final release of the EJB 3.0 JPA spec, section 6.2.1.6:
The set of managed persistence classes that are managed by a persistence unit 
is defined by using one or
more of the following:[41]
 • One or more object/relational mapping XML files
 • One or more jar files that will be searched for classes
 • An explicit list of the classes
 • The annotated managed persistence classes contained in the root of the 
persistence unit (unless
 the exclude-unlisted-classes element is specified)

... further on...
All classes must be on the classpath to ensure that entity managers from 
different persistence units that
map the same class will be accessing the same identical class.

This says that if exclude-unlisted-classes is specified as true, then only the 
classes listed in  elements must be used in the PU. If it is specified 
as false, then the annotated classes must be included. It's the only thing that 
exclude-unlisted-classes affects. It doesn't affect classes from other units, 
and if false it doesn't say that  must be ignored, which is what the 
following code does in PersistenceUnitBuilder.java:

if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
} else {
gbeanData.clearAttribute("managedClassNames");
}

I removed the else block to leave:

if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
}

Without this Geronimo isn't JavaEE 5 compliant.



Edited the JIRA to add some formatting for readability.

> In the JPA persistence.xml loading code, exclude-unlisted-classes handling 
> not compliant with JPA3.0 spec
> -
>
> Key: GERONIMO-4928
> URL: https://issues.apache.org/jira/browse/GERONIMO-4928
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, persistence
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
> Fix For: 2.1.4, 2.2, 3.0
>
> Attachments: external-jpa-entity-reference.patch
>
>
> {panel:title=EJB 3.0 JPA spec FR, section 6.2.1.6}
> The set of managed persistence classes that are managed by a persistence unit 
> is defined by using one or
> more of the following:[41]
>  • One or more object/relational mapping XML files
>  • One or more jar files that will be searched for classes
>  • An explicit list of the classes
>  • The annotated managed persistence classes contained in the root of the 
> persistence unit (unless
>  the exclude-unlisted-classes element is specified)
> {panel}
> {panel:title=further on in the same section}
> All classes must be on the classpath to ensure that entity managers from 
> different persistence units that
> map the same class

[jira] Updated: (GERONIMO-4928) In the JPA persistence.xml loading code, exclude-unlisted-classes handling not compliant with JPA3.0 spec

2009-10-23 Thread Quintin Beukes (JIRA)


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

Quintin Beukes updated GERONIMO-4928:
-

Attachment: external-jpa-entity-reference.patch

Changes the handling of exclude-unlisted-classes

> In the JPA persistence.xml loading code, exclude-unlisted-classes handling 
> not compliant with JPA3.0 spec
> -
>
> Key: GERONIMO-4928
> URL: https://issues.apache.org/jira/browse/GERONIMO-4928
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, persistence
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
> Fix For: 2.1.4, 2.2, 3.0
>
> Attachments: external-jpa-entity-reference.patch
>
>
> According to the final release of the EJB 3.0 JPA spec, section 6.2.1.6:
> The set of managed persistence classes that are managed by a persistence unit 
> is defined by using one or
> more of the following:[41]
>  • One or more object/relational mapping XML files
>  • One or more jar files that will be searched for classes
>  • An explicit list of the classes
>  • The annotated managed persistence classes contained in the root of the 
> persistence unit (unless
>  the exclude-unlisted-classes element is specified)
> ... further on...
> All classes must be on the classpath to ensure that entity managers from 
> different persistence units that
> map the same class will be accessing the same identical class.
> This says that if exclude-unlisted-classes is specified as true, then only 
> the classes listed in  elements must be used in the PU. If it is 
> specified as false, then the annotated classes must be included. It's the 
> only thing that exclude-unlisted-classes affects. It doesn't affect classes 
> from other units, and if false it doesn't say that  must be ignored, 
> which is what the following code does in PersistenceUnitBuilder.java:
> if (excludeUnlistedClasses) {
> gbeanData.clearAttribute("jarFileUrls");
> } else {
> gbeanData.clearAttribute("managedClassNames");
> }
> I removed the else block to leave:
> if (excludeUnlistedClasses) {
> gbeanData.clearAttribute("jarFileUrls");
> }
> Without this Geronimo isn't JavaEE 5 compliant.

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

Re: Persistence unit annotation having no effect

2009-10-23 Thread Quintin Beukes

Hey,

I found why this is happening and have submitted a patch. Unless I
misinterpret the spec, without it Geronimo isn't EJB3.0 JPA (JavaEE 5)
compliant. David, please correct me if I'm wrong.

The JIRA explains in detail:
https://issues.apache.org/jira/browse/GERONIMO-4928

Quintin Beukes



On Fri, Oct 23, 2009 at 3:25 PM, Quintin Beukes  wrote:
> Hey,
>
> When doing unit tests, this work fine. But as soon as I deploy the app
> to Geronimo, it fails.
>
> I have 2 jars A and B. B depends on A, and both have entities classes.
> Some of the entities in B reference (foreign keys) entities in A. So
> to get this working I add the classes in in A I'm referencing to B's
> persistence unit.
>
> When I unit test, this works perfectly. But as soon as I deploy it, I
> get the following:
> 2009-10-23 15:18:26,400 INFO  [config] Configuring enterprise
> application: net.kunye/VDS-lamps-ejb/3.0/jar
> 2009-10-23 15:18:26,807 INFO  [OpenEJB] Auto-deploying ejb LampBean:
> EjbDeployment(deployment-id=VDS-lamps-ejb/LampBean)
> 2009-10-23 15:18:26,808 INFO  [config] Enterprise application
> "net.kunye/VDS-lamps-ejb/3.0/jar" loaded.
> 2009-10-23 15:18:28,719 INFO  [Ejb3Configuration] Processing
> PersistenceUnitInfo [
>        name: VDS-lamps-PU
>        ...]
> 2009-10-23 15:18:28,961 INFO  [AnnotationBinder] Binding entity from
> annotated class: net.kunye.vds.lamps.LampAssignment
> 2009-10-23 15:18:28,962 INFO  [EntityBinder] Bind entity
> net.kunye.vds.lamps.LampAssignment on table LampAssignment
> 2009-10-23 15:18:29,004 INFO  [AnnotationBinder] Binding entity from
> annotated class: net.kunye.vds.lamps.Lamp
> 2009-10-23 15:18:29,004 INFO  [EntityBinder] Bind entity
> net.kunye.vds.lamps.Lamp on table Lamp
> 2009-10-23 15:18:29,017 INFO  [AnnotationBinder] Binding entity from
> annotated class: net.kunye.vds.lamps.LampFault
> 2009-10-23 15:18:29,017 INFO  [EntityBinder] Bind entity
> net.kunye.vds.lamps.LampFault on table LampFault
> 2009-10-23 15:18:29,018 INFO  [AnnotationBinder] Binding entity from
> annotated class: net.kunye.vds.lamps.LampTest
> 2009-10-23 15:18:29,019 INFO  [EntityBinder] Bind entity
> net.kunye.vds.lamps.LampTest on table LampTest
> 2009-10-23 15:18:29,033 ERROR [GBeanInstanceState] Error while
> starting; GBean is now in the FAILED state:
> abstractName="net.kunye/VDS-lamps-ejb/3.0/jar?EJBModule=net.kunye/VDS-lamps-ejb/3.0/jar,J2EEApplication=null,PersistenceUnitModule=ejb.jar,j2eeType=PersistenceUnit,name=VDS-lamps-PU"
> org.hibernate.AnnotationException: @OneToOne or @ManyToOne on
> net.kunye.vds.lamps.LampAssignment.employee references an unknown
> entity: net.kunye.personnel.Employee
>        at 
> org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:81)
>        at 
> org.hibernate.cfg.AnnotationConfiguration.processEndOfQueue(AnnotationConfiguration.java:456)
>        at 
> org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:438)
>        at 
> org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:309)
>        at 
> org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1162)
>        at 
> org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
>        at 
> org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
>        at 
> org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
>        at 
> org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
>        at 
> org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
>        at 
> org.apache.geronimo.persistence.PersistenceUnitGBean.(PersistenceUnitGBean.java:127)
>        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
>        at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>        at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>        at 
> org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
>        at 
> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
>        at 
> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
>        at 
> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
>        at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910)
>        at 
> org.apache.geronimo.gbean.runt

[jira] Created: (GERONIMO-4928) In the JPA persistence.xml loading code, exclude-unlisted-classes handling not compliant with JPA3.0 spec

2009-10-23 Thread Quintin Beukes (JIRA)

In the JPA persistence.xml loading code, exclude-unlisted-classes handling not 
compliant with JPA3.0 spec
-

 Key: GERONIMO-4928
 URL: https://issues.apache.org/jira/browse/GERONIMO-4928
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment, persistence
Affects Versions: 2.1.4
Reporter: Quintin Beukes
 Fix For: 2.2, 3.0, 2.1.4


According to the final release of the EJB 3.0 JPA spec, section 6.2.1.6:
The set of managed persistence classes that are managed by a persistence unit 
is defined by using one or
more of the following:[41]
 • One or more object/relational mapping XML files
 • One or more jar files that will be searched for classes
 • An explicit list of the classes
 • The annotated managed persistence classes contained in the root of the 
persistence unit (unless
 the exclude-unlisted-classes element is specified)

... further on...
All classes must be on the classpath to ensure that entity managers from 
different persistence units that
map the same class will be accessing the same identical class.

This says that if exclude-unlisted-classes is specified as true, then only the 
classes listed in  elements must be used in the PU. If it is specified 
as false, then the annotated classes must be included. It's the only thing that 
exclude-unlisted-classes affects. It doesn't affect classes from other units, 
and if false it doesn't say that  must be ignored, which is what the 
following code does in PersistenceUnitBuilder.java:

if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
} else {
gbeanData.clearAttribute("managedClassNames");
}

I removed the else block to leave:

if (excludeUnlistedClasses) {
gbeanData.clearAttribute("jarFileUrls");
}

Without this Geronimo isn't JavaEE 5 compliant.


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

OSGi and Deployment Plans

2009-10-23 Thread Quintin Beukes

Hey,

Just curious, but would the Geronimo 2 deployment plans change
tremendously on the OSGi'd Geronimo 3? If so, I assume Maven is
superceded with OSGi dependency management?

Quintin Beukes

Re: geronimo_home environment variable

2009-10-23 Thread Quintin Beukes

As everyone says.

Just to explain it and give a tip for the future. *HOME, *DIR and
*FILE variables usually need to point to the directory where the
application is installed. *PATH variables usually contain a list of
paths to search. This isn't a standard, but in general this works.
It's always best to determine the value from the the purpose of the
variable, ie. if it's and indication of where something is located,
then it's a single path component. If it's a search strategy, then
it's usually a list of path components (ex. GERONIMO_HOME and
CLASSPATH respectively).

Quintin Beukes

On Fri, Oct 23, 2009 at 4:57 AM, Forrest Xia  wrote:
> The geronimo_home should be like this:
>
> GERONIMO_HOME=C:\geronimo_home\geronimo-tomcat6-javaee5-2.1.4
>
> Good luck!
>
> Forrest
>

Singletons in Geronimo

2009-10-22 Thread Quintin Beukes

Hey,

I got Singletons working in Geronimo. I've uploaded patches a few
times, but this is the first one where I feel farely stable. I've
tested it remotely (same machine, network and now over the internet).
I've uploaded @Startup singletons with dependency heirachies, misc
injections and so on. The modifications to OpenEJB also continue
working without Geronimo (tested in embedded mode).

Unfortunately the only way I could see how to get the @Startup working
was to modify OpenEJB to create a property which gives the
responsibility over to Geronimo, and there the only way was to create
a new GBean which has it's lifecycle doStart() called after all EJBs
are in the RUNNING state.

I couldn't find a better way.

Not sure if you guys will use this, though I uploaded it anyway. We
needed it urgently so I took it upon myself to get it running.

The 2 tickets are:
- https://issues.apache.org/jira/browse/OPENEJB-1092
- https://issues.apache.org/jira/browse/GERONIMO-4918

The Geronimo modification depends on the OpenEJB modification (for the
startup responsibility).

Are singletons planned for Geronimo 2.2? It might pose a problem,
because unless another method is found where OpenEJB doesn't need to
be modified, 3.1.2 would have to be revoted and rereleased.

Quintin Beukes

[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used


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

Quintin Beukes updated GERONIMO-4918:
-

Attachment: SingletonDeploymentGBean.java
LoadOnStartupGBean.java
geronimo-singleton-support-geronimo.patch

Updated the patch and files. These new ones include the following:

1. Support to deploy Singleton beans
2. Fixes a wording error in an exception in 
plugins/openejb/geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/deployment/EjbDeploymentBuilder.java
3. Fixes a deadlock when an EJB is annotated with @Startup

Now Singleton beans can deploy and startup, with @DependsOn requirements and 
@PostConstruct methods executed. Beans can also be referenced remotely as well 
as locally. All necessary EJBs/resources/PU/etc are injected. 

I tested it with simple test EJB jars, as well as our software's relatively 
complex JARs which contain Singletons. Some jars had @Startup annotations, some 
didn't. Everything worked the same.

Still depends on OPENEJB-1092

> Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 
> is used
> 
>
> Key: GERONIMO-4918
> URL: https://issues.apache.org/jira/browse/GERONIMO-4918
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.2
>Reporter: Quintin Beukes
> Fix For: 2.2, 3.0
>
> Attachments: geronimo-singleton-support-geronimo.patch, 
> LoadOnStartupGBean.java, SingletonDeploymentGBean.java
>
>
> The singleton support hasn't been completely implemented, so it's impossible 
> to deploy an singleton session bean (EJB).
> I added the support, recompiled + tested and it's working.
> The patch requires creating a new file, so both need to be applied.
> The patch was made from the root of the svn checkout of branches/2.2. 
> The new files path from the same root is: 
> plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java

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

[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used


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

Quintin Beukes updated GERONIMO-4918:
-

Attachment: (was: SingletonDeploymentGBean.java)

> Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 
> is used
> 
>
> Key: GERONIMO-4918
> URL: https://issues.apache.org/jira/browse/GERONIMO-4918
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.2
>Reporter: Quintin Beukes
> Fix For: 2.2, 3.0
>
>
> The singleton support hasn't been completely implemented, so it's impossible 
> to deploy an singleton session bean (EJB).
> I added the support, recompiled + tested and it's working.
> The patch requires creating a new file, so both need to be applied.
> The patch was made from the root of the svn checkout of branches/2.2. 
> The new files path from the same root is: 
> plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java

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

[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used


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

Quintin Beukes updated GERONIMO-4918:
-

Attachment: (was: geronimo-singleton-support-geronimo.patch)

> Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 
> is used
> 
>
> Key: GERONIMO-4918
> URL: https://issues.apache.org/jira/browse/GERONIMO-4918
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.2
>Reporter: Quintin Beukes
> Fix For: 2.2, 3.0
>
>
> The singleton support hasn't been completely implemented, so it's impossible 
> to deploy an singleton session bean (EJB).
> I added the support, recompiled + tested and it's working.
> The patch requires creating a new file, so both need to be applied.
> The patch was made from the root of the svn checkout of branches/2.2. 
> The new files path from the same root is: 
> plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java

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

[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used


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

Quintin Beukes updated GERONIMO-4918:
-

Attachment: (was: singleton.patch)

> Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 
> is used
> 
>
> Key: GERONIMO-4918
> URL: https://issues.apache.org/jira/browse/GERONIMO-4918
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.2
>Reporter: Quintin Beukes
> Fix For: 2.2, 3.0
>
> Attachments: geronimo-singleton-support-geronimo.patch, 
> SingletonDeploymentGBean.java
>
>
> The singleton support hasn't been completely implemented, so it's impossible 
> to deploy an singleton session bean (EJB).
> I added the support, recompiled + tested and it's working.
> The patch requires creating a new file, so both need to be applied.
> The patch was made from the root of the svn checkout of branches/2.2. 
> The new files path from the same root is: 
> plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java

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

[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used


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

Quintin Beukes updated GERONIMO-4918:
-

Attachment: geronimo-singleton-support-geronimo.patch

Replaces the previous singleton.patch. This still depends on the 
SingletonDeploymentGBean.java to be created.

This patch adds the support (same as singleton.patch), but also fixes a 
deadlock when the @Startup annotation is used on a @Singleton session bean.

This patch also depends on OPENEJB-1092.

> Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 
> is used
> 
>
> Key: GERONIMO-4918
> URL: https://issues.apache.org/jira/browse/GERONIMO-4918
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.2
>Reporter: Quintin Beukes
> Fix For: 2.2, 3.0
>
> Attachments: geronimo-singleton-support-geronimo.patch, 
> singleton.patch, SingletonDeploymentGBean.java
>
>
> The singleton support hasn't been completely implemented, so it's impossible 
> to deploy an singleton session bean (EJB).
> I added the support, recompiled + tested and it's working.
> The patch requires creating a new file, so both need to be applied.
> The patch was made from the root of the svn checkout of branches/2.2. 
> The new files path from the same root is: 
> plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java

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

Re: How to build and run geronimo OSGi-transformed framework

2009-10-22 Thread Quintin Beukes

Hey,

Thanks a lot for this :>

Quintin Beukes

On Thu, Oct 22, 2009 at 9:13 AM, Forrest Xia  wrote:
> I saw some changes happened in geronimo framework code tree, those are the
> attempts to transform geronimo framework modules to OSGi bundles.
>
> I am eager to know how it works, so I made some effort to pull the code and
> try to make a build by self. Although the build process is not so smoothly,
> I finally make it work. That's excited, isn't it? Here are the steps for
> those who want to work on or study the Geronimo OSGi transformation :-)
>
> 1. install and config build softwares
> 1.1 maven 2.0.10
> 1.2 subversion
> 1.3 sun jdk 1.5 or 1.6
>
> 2. checkout and build servicemix4 bundles.
> ServiceMix4 bundles are required by the new geronimo framework. The build
> process is problematic and tricky, be patient :-)
>   $ svn co http://svn.apache.org/repos/asf/servicemix/smx4/all/ smx4all
>   $ cd smx4all
>   $ mvn install -e
> if you encounter error like "missing bundles-pom", do as follows:
>   $ cd bundles/bundles-pom
>   $ mvn install -e
> After successfully built bundles-pom, you can start to build bundles
>   $ cd ..
>   $ mvn install -e
> If you hit problem that says missing certain specific version of
> bundles-pom, you need to manually update that bundle's pom.xml. In my case,
> the groovy-1.5.6 has old bundles-pom dependency, so change it to the new one
> "5-SNAPSHOT", then from the root of bundles, build again.
>   $ mvn install -e
> You need to make sure all bundles are successfully built and installed into
> your local maven repository.
>
> Besides, you need to build these bundles additionally:
>   org.apache.servicemix.bundles.jaxb-impl/2.1.6_2-SNAPSHOT
>   org.apache.servicemix.bundles.woodstox/3.2.8_1-SNAPSHOT
>   org.apache.servicemix.bundles.jline/0.9.94_2-SNAPSHOT
>
> 3. Check out and build felix bundles.
> Not all of felix bundles need to be built. For my experience, these bundles
> are required:
>   org.osgi.core
>   org.osgi.foundation
>   org.osgi.compendium
>
>
> 4. check out and build geronimo framework
> check out geronimo code from trunk
>   $ svn co http://svn.apache.org/repos/asf/geronimo/server/trunk/ gtrunk
> build from framework
>   $ cd gtrunk/framework
>   $ mvn install -e
> You will hit bundle missing problems. Go to bundles sub directory and
> manually build each bundle, until all bundles are built successfully.
>   $ cd bundles/asm-3.1
>   $ mvn install -e
>   $ cd ../asm-commons-3.1
>   $ mvn install -e
>   ...
> The order is:
>   asm-3.1  asm-commons-3.1  commons-cli  log4j  plexus-utils plexus-logging
> plexus-archiver  sxc-jaxb  sxc-runtime
> You might encounter dependency missing errors when building plexus-logging,
> plexus-archiver sxc-jaxb sxc-runtime, resolve them like this:
>   For plexus-logging and plexus-archiver, update plexus-utils' version in
> pom.xml to the one you just built
>   For sxc-jaxb, you need to build "org.apache.servicemix.bundles.jaxb-impl",
> back to servicemix4 source tree and find it to build
>
> Back to framework directory, and build again:
>   $ mvn install -e
>
> You might to need to download some bundles manually. For my experience,
> these bundles are manually downloaded and installed:
>   wget
> http://repository.code-house.org/content/repositories/release/org/osgi/org.osgi.impl.bundle.jmx/4.2.0.200907080519/org.osgi.impl.bundle.jmx-4.2.0.200907080519.jar
>    mvn install:install-file -DgroupId=org.osgi
> -DartifactId=org.osgi.impl.bundle.jmx -Dversion=4.2.0.200907080519
> -Dpackaging=jar -Dfile=org.osgi.impl.bundle.jmx-4.2.0.200907080519.jar
>
> 5. After you see success prompt, you can try to run osgi-ed geronimo
> framework like this:
>   $ cd /framework/assemblies/geronimo-framework/target/assembly/bin
>   $ chmod +x *
>   $ ./karaf
> Auto-properties start: org.osgi.framework.BundleException: Fragment bundles
> can not be started.
> log4j:WARN No appenders could be found for logger
> (org.ops4j.pax.url.commons.handler.HandlerActivator).
> log4j:WARN Please initialize the log4j system properly.
>     __ __  
>    / //_/ __ _/ __/
>   / ,<  / __ `/ ___/ __ `/ /_
>  / /| |/ /_/ / /  / /_/ / __/
>     /_/ |_|\__,_/_/   \__,_/_/
>
>   Apache Felix Karaf (1.1.0-SNAPSHOT)
>
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or 'osgi:shutdown' to shutdown Karaf.
>
> ka...@root> Module 1/5
> org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car
> started in   .000s
> Module 2/5
> org.apache.geronimo.framework/rmi-na

Re: osgi >> trunk

2009-10-21 Thread Quintin Beukes

>
> I don't think I know enough about osgi and blueprint to say what direction
> we should go in yet.
>
> thanks
> david jencks
>
>>
>> Quintin Beukes
>>
>>
>>
>> On Sat, Oct 17, 2009 at 7:02 PM, David Jencks 
>> wrote:
>>>
>>> On Oct 17, 2009, at 5:04 AM, Quintin Beukes wrote:
>>>
>>>> Is it tricky to build? I would like to take a look at what you guys
>>>> have achieved so far :>
>>>
>>> It's beyond tricky, only the framework builds so far.  For that, you need
>>> to
>>> build some servicemix bundles locally.  I'll try to publish the
>>> servicemix
>>> bundles in the next few days.  There have been a few posts recently about
>>> how to get the framework to build, I would consult them for additional
>>> hints.
>>>
>>> I'm trying to get plugins/j2ee to build: at that point it should be
>>> possible
>>> for lots of people to work more or less independently in parallel on
>>> fixing
>>> the other plugins.
>>>
>>> thanks
>>> david jencks

Thanks for taking the time to respond. I understand you guys are very
busy. I'm very excited to see this working. Especially the Aries
project. I read through the Aries site the other day and it sounded
fantastic!

Q

Bug in @Startup annotations found - anyone have a possible solution?

2009-10-21 Thread Quintin Beukes

Hey,

I found why @Startup causes a deadlock for Singleton beans.

When a bean is annotated with @Startup, at the end of
SingletonContainer.deploy(DeploymentInfo) the following block is
executed:
if (deploymentInfo.isLoadOnStartup()){
try {
ThreadContext callContext = new
ThreadContext(deploymentInfo, null);
ThreadContext old = ThreadContext.enter(callContext);
try {
instanceManager.getInstance(callContext);
} finally{
ThreadContext.exit(old);
}
} catch (OpenEJBException e) {
throw new OpenEJBException("Singleton startup failed:
"+deploymentInfo.getDeploymentID(), e);
}
}

Now, threadContext.enter() calls all
ThreadContextListener.contextEntered() methods, which is only
GeronimoThreadContextListener. This class has a the following:
 synchronized (deploymentInfo) {
if (deploymentInfo.get(EjbDeployment.class) == null) {
if (!deploymentInfo.isDestroyed()) {
try {
deploymentInfo.wait();
} catch (InterruptedException e) {
log.warn("Wait on deploymentInfo interrupted
unexpectedly");
}
}
}
}
}

At this point deploymentInfo.get(EjbDeployment.class) returns null,
because it only gets set AFTER the bean has been deployed
(Container.deploy()) returns. Since it's null, and it's not
"destroyed", it goes into a wait() on deploymentInfo, which never
finished and thus holds up thread. From the point onwards OpenEJB's
deployer is held up, and you can continue/deploy/undeploy.

Anyone have a suggestion for how to fix this?

It could be possible to NOT do the isLoadOnStartup() code inside the
SingletonContainer.deploy() method, and execute it at some later time?
Or since a .notifyAll() is called when EjbDeployment.class is set on
the DeploymentInfo object, one could perhaps fork the
isLoadOnStartup() code to an alternative thread? This seems ugly
though.


Alternatively one could execute the isLoadOnStartup() code at a later
time (only after the EjbDeployment.class has been set). Though at
first glance I could find a place to put this code which would leave
OpenEJB's code independent as well as provide the facility to
Geronimo.

Any ideas would be appreciated.

Quintin Beukes

Fwd: Central Artifact Metadata Outdated

2009-10-19 Thread Quintin Beukes

I'm not sure if you guys are in charge of deploying the XBean project
to the Maven Central repository, but I'm getting the following and
they said the problem is on the deployer's side.

Message follows:
---
Hey,

I'm getting the following, repeatedly. It's being downloaded via
Nexus, but I repeatedly get the following messages (everytime it's
checked for updates):

Downloading: 
http://blade:7081/nexus/content/groups/public/org/apache/xbean/xbean-asm-shaded/3.6/xbean-asm-shaded-3.6.jar
118K downloaded  (xbean-asm-shaded-3.6.jar)
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'0a394260d8d16ba233796bc68b5f4188442e37fe'; remote =
'3e5ce3998772b6a8ccd401ee1caf33fd8949c8d2' - RETRYING
Downloading: 
http://blade:7081/nexus/content/groups/public/org/apache/xbean/xbean-asm-shaded/3.6/xbean-asm-shaded-3.6.jar
118K downloaded  (xbean-asm-shaded-3.6.jar)
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'0a394260d8d16ba233796bc68b5f4188442e37fe'; remote =
'3e5ce3998772b6a8ccd401ee1caf33fd8949c8d2' - IGNORING

I checked the download at central, and the file's sha1sum against the
metadata file's value differs. Manually verifying gives the same
results as in the errors above.

Who manages Central, iow. how should I report this?

Quintin Beukes

Re: CXF + Geronimo + Spring= working example?

2009-10-19 Thread Quintin Beukes

You might be able to get better results on the user list. There is a
bigger likeliness of someone having done what you are trying.

What problems are you having? Did you enable CXF?

Quintin Beukes



On Mon, Oct 19, 2009 at 1:36 PM, Westhveg  wrote:
>
> Hello,
>
> I'm finding many problems when I try to publish and consume a CXF webservice
> using spring and Apache Geronimo. Can anyone send me a working example? My
> email is: westhstudios[a]gmail.com
>
>
> Thanks,
>
> Westhveg
> --
> View this message in context: 
> http://www.nabble.com/CXF-%2B-Geronimo-%2B-Spring%3D-working-example--tp25956828s134p25956828.html
> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
>
>

[jira] Updated: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used

2009-10-19 Thread Quintin Beukes (JIRA)


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

Quintin Beukes updated GERONIMO-4918:
-

Attachment: SingletonDeploymentGBean.java
singleton.patch

Apply "singleton.patch" to branches/2.2.
Commit SingletonDeploymentGBean.java to 
branches/2.2/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java


> Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 
> is used
> 
>
> Key: GERONIMO-4918
> URL: https://issues.apache.org/jira/browse/GERONIMO-4918
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.2
>Reporter: Quintin Beukes
> Fix For: 2.2, 3.0
>
> Attachments: singleton.patch, SingletonDeploymentGBean.java
>
>
> The singleton support hasn't been completely implemented, so it's impossible 
> to deploy an singleton session bean (EJB).
> I added the support, recompiled + tested and it's working.
> The patch requires creating a new file, so both need to be applied.
> The patch was made from the root of the svn checkout of branches/2.2. 
> The new files path from the same root is: 
> plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java

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

[jira] Created: (GERONIMO-4918) Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is used

2009-10-19 Thread Quintin Beukes (JIRA)

Incomplete, not working support for singleton EJBs even though OpenEJB 3.1.2 is 
used


 Key: GERONIMO-4918
 URL: https://issues.apache.org/jira/browse/GERONIMO-4918
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: OpenEJB
Affects Versions: 2.2
Reporter: Quintin Beukes
 Fix For: 2.2, 3.0


The singleton support hasn't been completely implemented, so it's impossible to 
deploy an singleton session bean (EJB).

I added the support, recompiled + tested and it's working.

The patch requires creating a new file, so both need to be applied.

The patch was made from the root of the svn checkout of branches/2.2. 
The new files path from the same root is: 
plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/SingletonDeploymentGBean.java

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

Re: [jira] Updated: (GERONIMO-4915) SVN urls on the site is outdated/wrong

2009-10-19 Thread Quintin Beukes

I don't know how the site release process work, but I ran "mvn site"
for my branches/2.2 checkout and no site was generated for the
maven-plugin. Maybe when the site is generated and assembled it gets
copied over, and since there is no override it just leaves the other
intact?

I also received a lot of these. Maybe it's related.
java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl
at 
com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46)
at 
com.sun.tools.doclets.internal.toolkit.util.Util.isDeprecated(Util.java:804)
at 
com.sun.tools.doclets.formats.html.TagletWriterImpl.deprecatedTagOutput(TagletWriterImpl.java:85)
at 
com.sun.tools.doclets.internal.toolkit.taglets.DeprecatedTaglet.getTagletOutput(DeprecatedTaglet.java:40)
at 
com.sun.tools.doclets.formats.html.MethodWriterImpl.writeDeprecated(MethodWriterImpl.java:166)
at 
com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildDeprecationInfo(MethodBuilder.java:183)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109)
at 
com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90)
at 
com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56)
at 
com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:150)
at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109)
at 
com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90)
at 
com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56)
at 
com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:322)
at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101)
at 
com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90)
at 
com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:124)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101)
at 
com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90)
at 
com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:108)
at 
com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:155)
at 
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:164)
at 
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:106)
at 
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64)
at 
com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42)
at com.sun.tools.doclets.standard.Standard.start(Standard.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269)
at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143)
at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340)
at com.sun.tools.javadoc.Start.begin(Start.java:128)
at com.sun.tools.javadoc.Main.execute(Main.java:41)
at com.sun.tools.javadoc.Main.main(Main.java:31)

Quintin Beukes

On Mon, Oct 19, 2009 at 7:46 AM, Shawn Jiang  wrote:
>
>
> On Sat, Oct 17, 2009 at 10:58 PM, chi runhua  wrote:
>>
>> Thanks for reporting t

Re: osgi >> trunk

2009-10-18 Thread Quintin Beukes

What exactly will be the affect OSGi will have on Geronimo?

Will it simply replace the plugin architecture?

And how will it, if at all, affect gbeans?

Quintin Beukes



On Sat, Oct 17, 2009 at 7:02 PM, David Jencks  wrote:
>
> On Oct 17, 2009, at 5:04 AM, Quintin Beukes wrote:
>
>> Is it tricky to build? I would like to take a look at what you guys
>> have achieved so far :>
>
> It's beyond tricky, only the framework builds so far.  For that, you need to
> build some servicemix bundles locally.  I'll try to publish the servicemix
> bundles in the next few days.  There have been a few posts recently about
> how to get the framework to build, I would consult them for additional
> hints.
>
> I'm trying to get plugins/j2ee to build: at that point it should be possible
> for lots of people to work more or less independently in parallel on fixing
> the other plugins.
>
> thanks
> david jencks
>
>>
>> Quintin Beukes
>>
>>
>>
>> On Fri, Oct 16, 2009 at 10:41 PM, David Jencks 
>> wrote:
>>>
>>> Thanks Donald,
>>>
>>> I opened GERONIMO-4916 to track this, removed the old framework, and
>>> moved
>>> over the osgi framework from sandbox.
>>>
>>> Now we just have to get it all to work :-)
>>>
>>> thanks
>>> david jencks
>>>
>>> On Oct 16, 2009, at 12:30 PM, Donald Woods wrote:
>>>
>>>> Branch of current pre-OSGi trunk has been created at -
>>>> https://svn.apache.org/repos/asf/geronimo/server/branches/3.0_old/
>>>>
>>>> Let the OSGi merge begin
>>>>
>>>>
>>>> -Donald
>>>>
>>>>
>>>> David Jencks wrote:
>>>>>
>>>>> I have the sandbox osgi framework working enough to start the geronimo
>>>>> plugins, so I'm planning to move this work into trunk so we can all
>>>>> pitch in
>>>>> more easily on getting the rest of geronimo running on osgi.
>>>>> There's one legal issue to take care of first, since I copied in some
>>>>> plexus code that is not clearly available under asl2.  The code appears
>>>>> to
>>>>> have been derived from ant, so I'm going to see if we can get the same
>>>>> results by importing or using ant code.
>>>>> I think that Donald is planning to make a branch off of trunk for a
>>>>> convenient place to try out jpa2 stuff at least until we have the
>>>>> equivalent
>>>>> working under osgi.
>>>>> If you have any concerns about this please speak up!
>>>>> thanks
>>>>> david jencks
>>>
>>>
>
>

Re: [jira] Updated: (GERONIMO-4915) SVN urls on the site is outdated/wrong

2009-10-17 Thread Quintin Beukes

Yes, I also had a look at the site.xml and apt/ directories in the
Geronimo source, and couldn't find much of what is contained under the
Project Information pages of those Maven generated sites.

Quintin Beukes



On Sat, Oct 17, 2009 at 4:58 PM, chi runhua  wrote:
> Thanks for reporting this.
>
> I did a little bit digging and noticed the page is from [1], which is
> located within a section of page [2]
>
> No further result on how to edit [1].
>
> [1] http://geronimo.apache.org/maven/server/
> [2]
> http://cwiki.apache.org/confluence/display/GMOxDEV/Maven+Generated+Documentation
>
> Hope someone could shed more light on this issue.
>
> Jeff C
>
> On Sat, Oct 17, 2009 at 3:25 AM, Quintin Beukes (JIRA) 
> wrote:
>>
>>     [
>> https://issues.apache.org/jira/browse/GERONIMO-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Quintin Beukes updated GERONIMO-4915:
>> -
>>
>>    Description:
>> Currently on the page:
>> http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html
>>
>> The subversion URLs give 404 errors for these 3:
>>
>> http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin
>>
>> http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
>> geronimo-maven-plugin
>>
>> https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
>> geronimo-maven-plugin
>>
>> I'm not sure what they should be, as I have never seen the source and
>> can't verify if this is in fact the correct URL, though it seems like it
>> should be (in the same order):
>>
>> http://svn.apache.org/viewvc/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
>>
>> http://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
>>
>> https://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
>>
>>  was:
>> Currently on the page:
>> http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html
>>
>> The subversion URLs give 404 errors for these 3:
>>
>> http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin
>>
>> http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
>> geronimo-maven-plugin
>>
>> https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
>> geronimo-maven-plugin
>>
>> I'm not sure what they should be, as I have never seen the source and
>> can't verify if this is in fact the correct URL, though it seems like it
>> should be (in the same order):
>> http://svn.apache.org/viewvc/geronimo/devtools/maven-plugins/trunk/
>> http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/
>> https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/
>>
>>
>> Updated the URLs to the correct ones.
>>
>> > SVN urls on the site is outdated/wrong
>> > --
>> >
>> >                 Key: GERONIMO-4915
>> >                 URL: https://issues.apache.org/jira/browse/GERONIMO-4915
>> >             Project: Geronimo
>> >          Issue Type: Bug
>> >      Security Level: public(Regular issues)
>> >          Components: geronimo-maven-plugin
>> >            Reporter: Quintin Beukes
>> >
>> > Currently on the page:
>> > http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html
>> > The subversion URLs give 404 errors for these 3:
>> >
>> > http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin
>> >
>> > http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
>> > geronimo-maven-plugin
>> >
>> > https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
>> > geronimo-maven-plugin
>> > I'm not sure what they should be, as I have never seen the source and
>> > can't verify if this is in fact the correct URL, though it seems like it
>> > should be (in the same order):
>> >
>> > http://svn.apache.org/viewvc/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
>> >
>> > http://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
>> >
>> > https://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>
>

Re: osgi >> trunk

2009-10-17 Thread Quintin Beukes

Is it tricky to build? I would like to take a look at what you guys
have achieved so far :>

Quintin Beukes



On Fri, Oct 16, 2009 at 10:41 PM, David Jencks  wrote:
> Thanks Donald,
>
> I opened GERONIMO-4916 to track this, removed the old framework, and moved
> over the osgi framework from sandbox.
>
> Now we just have to get it all to work :-)
>
> thanks
> david jencks
>
> On Oct 16, 2009, at 12:30 PM, Donald Woods wrote:
>
>> Branch of current pre-OSGi trunk has been created at -
>> https://svn.apache.org/repos/asf/geronimo/server/branches/3.0_old/
>>
>> Let the OSGi merge begin
>>
>>
>> -Donald
>>
>>
>> David Jencks wrote:
>>>
>>> I have the sandbox osgi framework working enough to start the geronimo
>>> plugins, so I'm planning to move this work into trunk so we can all pitch in
>>> more easily on getting the rest of geronimo running on osgi.
>>> There's one legal issue to take care of first, since I copied in some
>>> plexus code that is not clearly available under asl2.  The code appears to
>>> have been derived from ant, so I'm going to see if we can get the same
>>> results by importing or using ant code.
>>> I think that Donald is planning to make a branch off of trunk for a
>>> convenient place to try out jpa2 stuff at least until we have the equivalent
>>> working under osgi.
>>> If you have any concerns about this please speak up!
>>> thanks
>>> david jencks
>
>

[jira] Updated: (GERONIMO-4915) SVN urls on the site is outdated/wrong

2009-10-16 Thread Quintin Beukes (JIRA)


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

Quintin Beukes updated GERONIMO-4915:
-

Description: 
Currently on the page: 
http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html

The subversion URLs give 404 errors for these 3:
http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin
http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
 geronimo-maven-plugin
https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
 geronimo-maven-plugin

I'm not sure what they should be, as I have never seen the source and can't 
verify if this is in fact the correct URL, though it seems like it should be 
(in the same order):
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
http://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
https://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/

  was:
Currently on the page: 
http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html

The subversion URLs give 404 errors for these 3:
http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin
http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
 geronimo-maven-plugin
https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
 geronimo-maven-plugin

I'm not sure what they should be, as I have never seen the source and can't 
verify if this is in fact the correct URL, though it seems like it should be 
(in the same order):
http://svn.apache.org/viewvc/geronimo/devtools/maven-plugins/trunk/
http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/
https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/


Updated the URLs to the correct ones.

> SVN urls on the site is outdated/wrong
> --
>
> Key: GERONIMO-4915
> URL: https://issues.apache.org/jira/browse/GERONIMO-4915
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: geronimo-maven-plugin
>Reporter: Quintin Beukes
>
> Currently on the page: 
> http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html
> The subversion URLs give 404 errors for these 3:
> http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin
> http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
>  geronimo-maven-plugin
> https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
>  geronimo-maven-plugin
> I'm not sure what they should be, as I have never seen the source and can't 
> verify if this is in fact the correct URL, though it seems like it should be 
> (in the same order):
> http://svn.apache.org/viewvc/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
> http://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/
> https://svn.apache.org/repos/asf/geronimo/server/trunk/framework/buildsupport/geronimo-maven-plugin/

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

[jira] Created: (GERONIMO-4915) SVN urls on the site is outdated/wrong

2009-10-16 Thread Quintin Beukes (JIRA)

SVN urls on the site is outdated/wrong
--

 Key: GERONIMO-4915
 URL: https://issues.apache.org/jira/browse/GERONIMO-4915
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: geronimo-maven-plugin
Reporter: Quintin Beukes


Currently on the page: 
http://geronimo.apache.org/maven/server/maven-plugins/geronimo-maven-plugin/source-repository.html

The subversion URLs give 404 errors for these 3:
http://svn.apache.org/viewvc/geronimo/trunk/maven-plugins/geronimo-maven-plugin
http://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
 geronimo-maven-plugin
https://svn.apache.org/repos/asf/geronimo/server/trunk/maven-plugins/geronimo-maven-plugin
 geronimo-maven-plugin

I'm not sure what they should be, as I have never seen the source and can't 
verify if this is in fact the correct URL, though it seems like it should be 
(in the same order):
http://svn.apache.org/viewvc/geronimo/devtools/maven-plugins/trunk/
http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/
https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/trunk/

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

Re: Wiki link to current version page

2009-10-16 Thread Quintin Beukes

I've also found that the search engines list very similar results for
most searches (from my experience at least). So usually optimizing for
Google ends up giving similar effects for all 3 major indexes
(Yahoo/Live/Google).

Beyond this, most other search engines just feed from one of these 3
indexes. The other "real" indexes are mostly insignificant.

Quintin Beukes



On Fri, Oct 16, 2009 at 11:08 AM, Quintin Beukes  wrote:
> I definitely recommend looking into an archive if possible. You should
> even be able to leave the documentation.html page's links the same,
> only changing the old docs to be hosted on another domain. If at all
> possible this would be a good solution to ensure the latest docs have
> as much indexed on google as possible.
>
> Quintin Beukes
>
>
>
> On Fri, Oct 16, 2009 at 3:39 AM, Ellen Tang  wrote:
>> Hi Quintin,
>>
>> Thank you for your advice. That's very useful for us. I'll look into SEO and
>> try to make our pages better.
>>
>> Best regards,
>>
>> Ellen
>>
>> 2009/10/14 Quintin Beukes 
>>>
>>> Futher, if the old docs are taken out, it would leave a structure
>>> that's much more focused on a the newest version, and thus reduce the
>>> likeliness of GoogleBot seeing the pages as being too similar.
>>> GoogleBot is very sensitive with this and sometimes sees 2 completely
>>> irrelevant pages as being similar. I've found on 2 occasions that
>>> changing the wording on one page could cause another page to suddenly
>>> appear with the next index. This could be coincidence, as many reasons
>>> could cause a page to become indexed, but the similarity seems most
>>> probably since looking at the 2 pages you could understand how a bot
>>> could see them as similar.
>>>
>>> Further, updating the documentation with basic SEO in mind, and
>>> improving the link webs should help get more pages indexed - and
>>> possibly even listed higher.
>>>
>>> Quintin Beukes
>>>
>>>
>>>
>>> On Wed, Oct 14, 2009 at 5:19 PM, Quintin Beukes 
>>> wrote:
>>> > The 2.2 docs are on google. In fact, all the versions are there. By
>>> > default it only lists 1/2 similar pages, and the rest can be viewed by
>>> > clicking on the "more results" link.
>>> >
>>> > From what I could see on the pages, the reason 1.1 docs are listed
>>> > first is an SEO issue, in that the 1.1 docs contain the word Geronimo
>>> > more, and has a ranked page linking to it. To host all the
>>> > documentation online would make a for a major SEO task added onto the
>>> > list. Maybe the best would be to add the old docs into an "archive"
>>> > (another domain would be best), link into the archive, and have only
>>> > the latest docs actually stored on the xwiki.apache.org domain. I
>>> > don't know if this is possible, but it should definitely clear up the
>>> > documentation issue.
>>> >
>>> > If you're unlucky the archive ends up ranking higher than the original
>>> > and you're back to where you started, though I think that would be
>>> > unlikely if there is a link trail to Geronimo from the xwiki root, and
>>> > back up wards (and the same for all apps). This should keep the rank
>>> > tree farely high, and an archive would be unlikely to overtake it.
>>> >
>>> > I'm no SEO expert, so this might not be the best advice, but it would
>>> > be what I would have done.
>>> >
>>> > Quintin Beukes
>>> >
>>> >
>>> >
>>> > On Wed, Oct 14, 2009 at 5:02 AM, Ellen Tang 
>>> > wrote:
>>> >> Hi, I found that the "I'm feeling lucky" function only takes you to the
>>> >> first website listed in Google responding to your query. This is why
>>> >> you are
>>> >> directed to 1.1 docs instead of 2.1. But I do see the problem that 2.2
>>> >> docs
>>> >> are not listed in Google.
>>> >>
>>> >> I've seen the Confluence help pages with the links of the latest
>>> >> version as
>>> >> you suggested. It works very well on the Confluence websites. I think
>>> >> it's a
>>> >> very good function but yet takes a lot effort to implement because we
>>> >> have
>>> >> so many pages and versions of G docs right

Re: Wiki link to current version page

2009-10-16 Thread Quintin Beukes

I definitely recommend looking into an archive if possible. You should
even be able to leave the documentation.html page's links the same,
only changing the old docs to be hosted on another domain. If at all
possible this would be a good solution to ensure the latest docs have
as much indexed on google as possible.

Quintin Beukes



On Fri, Oct 16, 2009 at 3:39 AM, Ellen Tang  wrote:
> Hi Quintin,
>
> Thank you for your advice. That's very useful for us. I'll look into SEO and
> try to make our pages better.
>
> Best regards,
>
> Ellen
>
> 2009/10/14 Quintin Beukes 
>>
>> Futher, if the old docs are taken out, it would leave a structure
>> that's much more focused on a the newest version, and thus reduce the
>> likeliness of GoogleBot seeing the pages as being too similar.
>> GoogleBot is very sensitive with this and sometimes sees 2 completely
>> irrelevant pages as being similar. I've found on 2 occasions that
>> changing the wording on one page could cause another page to suddenly
>> appear with the next index. This could be coincidence, as many reasons
>> could cause a page to become indexed, but the similarity seems most
>> probably since looking at the 2 pages you could understand how a bot
>> could see them as similar.
>>
>> Further, updating the documentation with basic SEO in mind, and
>> improving the link webs should help get more pages indexed - and
>> possibly even listed higher.
>>
>> Quintin Beukes
>>
>>
>>
>> On Wed, Oct 14, 2009 at 5:19 PM, Quintin Beukes 
>> wrote:
>> > The 2.2 docs are on google. In fact, all the versions are there. By
>> > default it only lists 1/2 similar pages, and the rest can be viewed by
>> > clicking on the "more results" link.
>> >
>> > From what I could see on the pages, the reason 1.1 docs are listed
>> > first is an SEO issue, in that the 1.1 docs contain the word Geronimo
>> > more, and has a ranked page linking to it. To host all the
>> > documentation online would make a for a major SEO task added onto the
>> > list. Maybe the best would be to add the old docs into an "archive"
>> > (another domain would be best), link into the archive, and have only
>> > the latest docs actually stored on the xwiki.apache.org domain. I
>> > don't know if this is possible, but it should definitely clear up the
>> > documentation issue.
>> >
>> > If you're unlucky the archive ends up ranking higher than the original
>> > and you're back to where you started, though I think that would be
>> > unlikely if there is a link trail to Geronimo from the xwiki root, and
>> > back up wards (and the same for all apps). This should keep the rank
>> > tree farely high, and an archive would be unlikely to overtake it.
>> >
>> > I'm no SEO expert, so this might not be the best advice, but it would
>> > be what I would have done.
>> >
>> > Quintin Beukes
>> >
>> >
>> >
>> > On Wed, Oct 14, 2009 at 5:02 AM, Ellen Tang 
>> > wrote:
>> >> Hi, I found that the "I'm feeling lucky" function only takes you to the
>> >> first website listed in Google responding to your query. This is why
>> >> you are
>> >> directed to 1.1 docs instead of 2.1. But I do see the problem that 2.2
>> >> docs
>> >> are not listed in Google.
>> >>
>> >> I've seen the Confluence help pages with the links of the latest
>> >> version as
>> >> you suggested. It works very well on the Confluence websites. I think
>> >> it's a
>> >> very good function but yet takes a lot effort to implement because we
>> >> have
>> >> so many pages and versions of G docs right now. Plus, once we have a
>> >> new
>> >> release, all the links need to be updated. As discussed with Jeff, we
>> >> can
>> >> first try to make our latest docs display in Google.
>> >>
>> >> Please let us know if you have any suggestions for that. Thank you!
>> >>
>> >> Best regards,
>> >> Ellen
>> >>
>> >> 2009/10/1 Juergen Weber 
>> >>>
>> >>> Fixing the links doesn't seem to be the general solution,
>> >>> e.g. with
>> >>> geronimo ra.xml and "I'm feeling lucky" you get the 1.1 docs, even if
>> >>> google
>> >>> knows the 2.1 docs.
>>

Re: GEP 2.2

2009-10-15 Thread Quintin Beukes

Can you please run and paste "svn info" from the route of your checkout.

Quintin Beukes



On Thu, Oct 15, 2009 at 4:18 PM, Johannes Weberhofer, Weberhofer GmbH
 wrote:
> Building the current 2.2 version of the trunk I'm constantly getting the
> following error:
>
> [INFO]
> 
> [INFO] Building Geronimo Eclipse Plugin :: Testsuite :: Launcher
> [INFO]    task-segment: [clean, install]
> [INFO]
> 
> [INFO] [clean:clean]
> [INFO] Deleting file-set:
> /srv/project/autobuild/gep/trunk/testsuite/launcher (included:
> [launcher/.metadata, launcher/eclipse, launcher/results,
> launcher/server_v2.2, launcher/server_v2.1, launcher/server_v2.0,
> launcher/workspace], excluded: [])
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Storing buildNumber: 20091015161556 at timestamp: 1255616156287
> [INFO] [site:attach-descriptor]
> [INFO] [install:install]
> [INFO] Installing
> /srv/project/autobuild/gep/trunk/testsuite/launcher/pom.xml to
> /srv/downloads/maven/org/apache/geronimo/devtools/testsuite-launcher/2.2.0/testsuite-launcher-2.2.0.pom
> [WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:test' is invalid. It
> will be ignored for artifact resolution. Reason: Not a v4.0.0 POM. for
> project org.jvnet.staxex:stax-ex at
> /srv/downloads/maven/org/jvnet/staxex/stax-ex/1.0/stax-ex-1.0.pom
> [INFO] [antrun:run {execution: run-testsuite}]
> [INFO] Executing tasks
>
>
> Is there any resolution for that issue?
>
> Best regards,
> Johannes
>

[jira] Commented: (GERONIMO-4906) DB connection problem


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

Quintin Beukes commented on GERONIMO-4906:
--

I remember now that I was using c3p0 with Hibernate. These were the options I 
was referring to:
http://www.mchange.com/projects/c3p0/index.html#configuring_connection_testing

> DB connection problem
> -
>
> Key: GERONIMO-4906
> URL: https://issues.apache.org/jira/browse/GERONIMO-4906
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.0.1
> Environment: Geronimo running on Windows server 2003 (Virtual Machine)
> Oracle 10g
> Driver jdbc 10.2.0.1
> Spring-Version: 2.0.2
> Hibernate-Version: 3.2.0.cr4
>Reporter: Jean-Jacques Parent
> Attachments: config.xml, Errors_samples.txt
>
>
> Your expertise on my problem will be helpful.
> Once a week, I get a DB connectivity problem with my application.
> No new DB transaction can be open. After a few minutes, the situation can 
> come back as normal, if not the Geronimo server has to be restarted.
> I ask our technicians about connectivity and performance, but they found 
> nothing wrong.
> I give you the stack trace in attachment with the different kind of error 
> message.
> You will see that it looks like a network problem, but maybe this could also 
> be due to a jdbc, timeout...? 
> My pool configuration is as follow
> Pool Min Size:25   
>   The minimum number of connections in the pool. The default is 0.
> Pool Max Size:140  
>   The maximum number of connections in the pool. The default is 10.
> Blocking Timeout: 5000 (in milliseconds)
>   The length of time a caller will wait for a connection. The default is 
> 5000.
> Idle Timeout: 5(in minutes)
>   How long a connection can be idle before being closed. The default is 
> 15.
> Any help will be appreciate.

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

[jira] Commented: (GERONIMO-4906) DB connection problem


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

Quintin Beukes commented on GERONIMO-4906:
--

I remember dealing with a similar problem once. I've been trying to think which 
pool manager this was, but am unable.

Though I do remember how it was solved. It was an an option (possible 2 
separate once - not sure) which routinely tested the actual connection, and if 
closed would remove it from the pool. Also, before the connection is given to a 
requesting client it would also be tested to ensure it's active, if not it 
would be removed and another connection tried - until one could be found. If 
none could be found an exception is raised.

Maybe such an option is available? And if not, I definitely recommend it be 
added.

If this isn't available yet, the code that requests the connection could 
perhaps (even temporarily) wrap the request in a method which has the above 
behavior (testing the connection and requesting a new one if the test fails). 
The pool should automatically remove it when an exception is raised, so I don't 
think this wrapper needs to worry about that.

> DB connection problem
> -
>
> Key: GERONIMO-4906
> URL: https://issues.apache.org/jira/browse/GERONIMO-4906
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.0.1
> Environment: Geronimo running on Windows server 2003 (Virtual Machine)
> Oracle 10g
> Driver jdbc 10.2.0.1
> Spring-Version: 2.0.2
> Hibernate-Version: 3.2.0.cr4
>Reporter: Jean-Jacques Parent
> Attachments: config.xml, Errors_samples.txt
>
>
> Your expertise on my problem will be helpful.
> Once a week, I get a DB connectivity problem with my application.
> No new DB transaction can be open. After a few minutes, the situation can 
> come back as normal, if not the Geronimo server has to be restarted.
> I ask our technicians about connectivity and performance, but they found 
> nothing wrong.
> I give you the stack trace in attachment with the different kind of error 
> message.
> You will see that it looks like a network problem, but maybe this could also 
> be due to a jdbc, timeout...? 
> My pool configuration is as follow
> Pool Min Size:25   
>   The minimum number of connections in the pool. The default is 0.
> Pool Max Size:140  
>   The maximum number of connections in the pool. The default is 10.
> Blocking Timeout: 5000 (in milliseconds)
>   The length of time a caller will wait for a connection. The default is 
> 5000.
> Idle Timeout: 5(in minutes)
>   How long a connection can be idle before being closed. The default is 
> 15.
> Any help will be appreciate.

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

[jira] Commented: (GERONIMO-4903) Jetty Advanced Integration Test Failure


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

Quintin Beukes commented on GERONIMO-4903:
--

If GERONIMO-4907 is applied, it could become an option to revert revision 
#824389 and #824390.

> Jetty Advanced Integration Test Failure
> ---
>
> Key: GERONIMO-4903
> URL: https://issues.apache.org/jira/browse/GERONIMO-4903
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 2.2
>Reporter: Quintin Beukes
>Assignee: Donald Woods
> Fix For: 2.2, 3.0
>
> Attachments: jetty-advanced-test-failure.patch
>
>
> Hey,
> I found the cause of the test failure.
> In the file: {src
> root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
> Line: 289
> It reads: new String[]{"host", "port", "minThreads", "maxThreads",
> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
> "lingerMillis", "protocol", "redirectPort", "connectUrl",
> "maxIdleTimeMs"},
> Change to: new String[]{"host", "port", "minThreads", "maxThreads",
> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
> "lingerMillis", "redirectPort", "maxIdleTimeMs"},
> Basically removing the "protocol" and "connectUrl" attributes from the
> persistent interface attributes fixes the problem.
> "protocol" is static for Jetty BIO connector, so it doesn't need to be
> saved, or can't be specified.
> "connectUrl" is generated on the fly through getConnectUrl(), so can't
> be saved either.
> So unless my understanding of what persistentAttributes are is
> incorrect, this seems to be the correct solution? Please correct me if
> I'm wrong.
> What caused the problem is that the JettyConnector class doesn't have
> a setter for these attributes, so when XBean searches all the
> specified attributes' setters, it fails when it can't find these. This
> caused the test to fail, because the connector doesn't start again
> after being edited (enters the failed state).

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

[jira] Commented: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters


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

Quintin Beukes commented on GERONIMO-4907:
--

If this is applied, GERONIMO-4903 could possibly be reversed.

> GBeanInstance to Ignore Missing Setters
> ---
>
> Key: GERONIMO-4907
> URL: https://issues.apache.org/jira/browse/GERONIMO-4907
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0
>Reporter: Quintin Beukes
> Fix For: 2.2, 3.0
>
> Attachments: ignore-missing-accessors.patch
>
>
> Related to GERONIMO-4903
> I submitted a patch which fixes the problem by removing the attributes which 
> don't have setters. 
> After reading the OpenEJB source I noticed an XBean feature which would be a 
> more correct fix for the problem.
> Instead of removing the attributes which won't have setters in the class 
> being instantiated as a GBean, configure the ObjectRecipe to rather ignore 
> those properties which don't have setters. This has 2 benefits
> 1) Those properties can still be included for "read" access
> 2) If such a property exists for any other GBean, or is added in the future, 
> this will help that those don't possibly create fatal bugs - which the 
> JettyConnector bug almost was (you couldn't edit a connector - ever).
> This is achieved by adding the following line after the ObjectRecipe was 
> created:
> objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES);
> This permissions merely removes the property from the list of properties to 
> "create the object with", if the accessor wasn't found. 
> Since those properties are still available, they can be accessed by the GBean 
> API, and thus it doesn't become a requirement to have setter accessors for 
> all persistent 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-4907) GBeanInstance to Ignore Missing Setters


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

Quintin Beukes updated GERONIMO-4907:
-

Attachment: ignore-missing-accessors.patch

Attached patch to add the IGNORE_MISSING_ACCESSOR option to the ObjectRecipe.

> GBeanInstance to Ignore Missing Setters
> ---
>
> Key: GERONIMO-4907
> URL: https://issues.apache.org/jira/browse/GERONIMO-4907
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0
>    Reporter: Quintin Beukes
> Fix For: 2.2, 3.0
>
> Attachments: ignore-missing-accessors.patch
>
>
> Related to GERONIMO-4903
> I submitted a patch which fixes the problem by removing the attributes which 
> don't have setters. 
> After reading the OpenEJB source I noticed an XBean feature which would be a 
> more correct fix for the problem.
> Instead of removing the attributes which won't have setters in the class 
> being instantiated as a GBean, configure the ObjectRecipe to rather ignore 
> those properties which don't have setters. This has 2 benefits
> 1) Those properties can still be included for "read" access
> 2) If such a property exists for any other GBean, or is added in the future, 
> this will help that those don't possibly create fatal bugs - which the 
> JettyConnector bug almost was (you couldn't edit a connector - ever).
> This is achieved by adding the following line after the ObjectRecipe was 
> created:
> objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES);
> This permissions merely removes the property from the list of properties to 
> "create the object with", if the accessor wasn't found. 
> Since those properties are still available, they can be accessed by the GBean 
> API, and thus it doesn't become a requirement to have setter accessors for 
> all persistent properties.

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

[jira] Created: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters

GBeanInstance to Ignore Missing Setters
---

 Key: GERONIMO-4907
 URL: https://issues.apache.org/jira/browse/GERONIMO-4907
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: kernel
Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0
Reporter: Quintin Beukes
 Fix For: 2.2, 3.0


Related to GERONIMO-4903

I submitted a patch which fixes the problem by removing the attributes which 
don't have setters. 

After reading the OpenEJB source I noticed an XBean feature which would be a 
more correct fix for the problem.

Instead of removing the attributes which won't have setters in the class being 
instantiated as a GBean, configure the ObjectRecipe to rather ignore those 
properties which don't have setters. This has 2 benefits
1) Those properties can still be included for "read" access
2) If such a property exists for any other GBean, or is added in the future, 
this will help that those don't possibly create fatal bugs - which the 
JettyConnector bug almost was (you couldn't edit a connector - ever).

This is achieved by adding the following line after the ObjectRecipe was 
created:
objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES);

This permissions merely removes the property from the list of properties to 
"create the object with", if the accessor wasn't found. 

Since those properties are still available, they can be accessed by the GBean 
API, and thus it doesn't become a requirement to have setter accessors for all 
persistent properties.

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

Re: Wiki link to current version page

2009-10-14 Thread Quintin Beukes

Futher, if the old docs are taken out, it would leave a structure
that's much more focused on a the newest version, and thus reduce the
likeliness of GoogleBot seeing the pages as being too similar.
GoogleBot is very sensitive with this and sometimes sees 2 completely
irrelevant pages as being similar. I've found on 2 occasions that
changing the wording on one page could cause another page to suddenly
appear with the next index. This could be coincidence, as many reasons
could cause a page to become indexed, but the similarity seems most
probably since looking at the 2 pages you could understand how a bot
could see them as similar.

Further, updating the documentation with basic SEO in mind, and
improving the link webs should help get more pages indexed - and
possibly even listed higher.

Quintin Beukes



On Wed, Oct 14, 2009 at 5:19 PM, Quintin Beukes  wrote:
> The 2.2 docs are on google. In fact, all the versions are there. By
> default it only lists 1/2 similar pages, and the rest can be viewed by
> clicking on the "more results" link.
>
> From what I could see on the pages, the reason 1.1 docs are listed
> first is an SEO issue, in that the 1.1 docs contain the word Geronimo
> more, and has a ranked page linking to it. To host all the
> documentation online would make a for a major SEO task added onto the
> list. Maybe the best would be to add the old docs into an "archive"
> (another domain would be best), link into the archive, and have only
> the latest docs actually stored on the xwiki.apache.org domain. I
> don't know if this is possible, but it should definitely clear up the
> documentation issue.
>
> If you're unlucky the archive ends up ranking higher than the original
> and you're back to where you started, though I think that would be
> unlikely if there is a link trail to Geronimo from the xwiki root, and
> back up wards (and the same for all apps). This should keep the rank
> tree farely high, and an archive would be unlikely to overtake it.
>
> I'm no SEO expert, so this might not be the best advice, but it would
> be what I would have done.
>
> Quintin Beukes
>
>
>
> On Wed, Oct 14, 2009 at 5:02 AM, Ellen Tang  wrote:
>> Hi, I found that the "I'm feeling lucky" function only takes you to the
>> first website listed in Google responding to your query. This is why you are
>> directed to 1.1 docs instead of 2.1. But I do see the problem that 2.2 docs
>> are not listed in Google.
>>
>> I've seen the Confluence help pages with the links of the latest version as
>> you suggested. It works very well on the Confluence websites. I think it's a
>> very good function but yet takes a lot effort to implement because we have
>> so many pages and versions of G docs right now. Plus, once we have a new
>> release, all the links need to be updated. As discussed with Jeff, we can
>> first try to make our latest docs display in Google.
>>
>> Please let us know if you have any suggestions for that. Thank you!
>>
>> Best regards,
>> Ellen
>>
>> 2009/10/1 Juergen Weber 
>>>
>>> Fixing the links doesn't seem to be the general solution,
>>> e.g. with
>>> geronimo ra.xml and "I'm feeling lucky" you get the 1.1 docs, even if
>>> google
>>> knows the 2.1 docs.
>>> There should be a friendly big red box on old pages "There exists a more
>>> recent version of this page" with a link to it.
>>>
>>> Greetings, Juergen
>>>
>>>
>>> Ellen Tang-2 wrote:
>>> >
>>> > I've tried to find the page of the same topic (Daytrader) in
>>> > documentation
>>> > v2.1 by changing the link directly from
>>> > http://cwiki.apache.org/GMOxDOC20/daytrader.html to
>>> > http://cwiki.apache.org/GMOxDOC21/daytrader.html . The page does open
>>> > and
>>> > has correct contents, but when I tried to find the link of the same
>>> > topic
>>> > in
>>> > the table of contents of v2.1 documentation (
>>> > http://cwiki.apache.org/GMOxDOC21/documentation.html ), I couldn't find
>>> > the
>>> > link for the "Daytrader" page, which does exist.
>>> >
>>> > I guess that this is why the google search can't find the page of
>>> > "Daytrader" in Geronimo v2.1 documentation.
>>> >
>>> > Jeff, maybe you can have a check for this to see if you get the same
>>> > result
>>> > as me.
>>> >
>>> > Thanks!
>>> >
>>> > Ellen

Re: Wiki link to current version page

2009-10-14 Thread Quintin Beukes

The 2.2 docs are on google. In fact, all the versions are there. By
default it only lists 1/2 similar pages, and the rest can be viewed by
clicking on the "more results" link.

>From what I could see on the pages, the reason 1.1 docs are listed
first is an SEO issue, in that the 1.1 docs contain the word Geronimo
more, and has a ranked page linking to it. To host all the
documentation online would make a for a major SEO task added onto the
list. Maybe the best would be to add the old docs into an "archive"
(another domain would be best), link into the archive, and have only
the latest docs actually stored on the xwiki.apache.org domain. I
don't know if this is possible, but it should definitely clear up the
documentation issue.

If you're unlucky the archive ends up ranking higher than the original
and you're back to where you started, though I think that would be
unlikely if there is a link trail to Geronimo from the xwiki root, and
back up wards (and the same for all apps). This should keep the rank
tree farely high, and an archive would be unlikely to overtake it.

I'm no SEO expert, so this might not be the best advice, but it would
be what I would have done.

Quintin Beukes



On Wed, Oct 14, 2009 at 5:02 AM, Ellen Tang  wrote:
> Hi, I found that the "I'm feeling lucky" function only takes you to the
> first website listed in Google responding to your query. This is why you are
> directed to 1.1 docs instead of 2.1. But I do see the problem that 2.2 docs
> are not listed in Google.
>
> I've seen the Confluence help pages with the links of the latest version as
> you suggested. It works very well on the Confluence websites. I think it's a
> very good function but yet takes a lot effort to implement because we have
> so many pages and versions of G docs right now. Plus, once we have a new
> release, all the links need to be updated. As discussed with Jeff, we can
> first try to make our latest docs display in Google.
>
> Please let us know if you have any suggestions for that. Thank you!
>
> Best regards,
> Ellen
>
> 2009/10/1 Juergen Weber 
>>
>> Fixing the links doesn't seem to be the general solution,
>> e.g. with
>> geronimo ra.xml and "I'm feeling lucky" you get the 1.1 docs, even if
>> google
>> knows the 2.1 docs.
>> There should be a friendly big red box on old pages "There exists a more
>> recent version of this page" with a link to it.
>>
>> Greetings, Juergen
>>
>>
>> Ellen Tang-2 wrote:
>> >
>> > I've tried to find the page of the same topic (Daytrader) in
>> > documentation
>> > v2.1 by changing the link directly from
>> > http://cwiki.apache.org/GMOxDOC20/daytrader.html to
>> > http://cwiki.apache.org/GMOxDOC21/daytrader.html . The page does open
>> > and
>> > has correct contents, but when I tried to find the link of the same
>> > topic
>> > in
>> > the table of contents of v2.1 documentation (
>> > http://cwiki.apache.org/GMOxDOC21/documentation.html ), I couldn't find
>> > the
>> > link for the "Daytrader" page, which does exist.
>> >
>> > I guess that this is why the google search can't find the page of
>> > "Daytrader" in Geronimo v2.1 documentation.
>> >
>> > Jeff, maybe you can have a check for this to see if you get the same
>> > result
>> > as me.
>> >
>> > Thanks!
>> >
>> > Ellen
>> >
>> > 2009/9/30 chi runhua 
>> >
>> >> I think it's the problem of the template in auto-export plugin,  but
>> >> only
>> >> confluence admin could do some configuration to update the template.
>> >>
>> >> Jeff C
>> >>
>> >> On Wed, Sep 30, 2009 at 10:12 AM, Ellen Tang
>> >> wrote:
>> >>
>> >>> Hi Juergen,
>> >>>
>> >>> I guess that could be a good thing to do. We'll discuss about that to
>> >>> see
>> >>> if it's possible and necessary to do that.
>> >>>
>> >>> Thank you for your idea!
>> >>>
>> >>> Best regards,
>> >>>
>> >>> Ellen
>> >>>
>> >>> 2009/9/28 Juergen Weber 
>> >>>
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> googling often leads to an old version of a Geronimo wiki page.
>> >>>> e.g. google daytrader apache goes to
>> >>>> http://cwiki.apache.org/GMOxDOC20/daytrader.html
>> >>>>
>> >>>> Can you somehow make the wiki automatically display links to the most
>> >>>> recent
>> >>>> version?
>> >>>>
>> >>>> Thanks,
>> >>>> Juergen
>> >>>> --
>> >>>> View this message in context:
>> >>>>
>> >>>> http://www.nabble.com/Wiki-link-to-current-version-page-tp25645167s134p25645167.html
>> >>>> Sent from the Apache Geronimo - Dev mailing list archive at
>> >>>> Nabble.com.
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wiki-link-to-current-version-page-tp25645167s134p25685083.html
>> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
>>
>
>

[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize


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

Quintin Beukes updated GERONIMO-4885:
-

Attachment: default-memory-options.patch

To summarize the patch:
Adds a -Xmx128m and -XX:MaxPermGen=128m as a default to bin/geronimo.sh, 
bin/geronimo.bat and etc/rc.d/start-server,default.groovy. For the groovy file 
it's only done for non Sun JRE 6 profiles.

> Configure default max heap and max permsize
> ---
>
> Key: GERONIMO-4885
> URL: https://issues.apache.org/jira/browse/GERONIMO-4885
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: Kevan Miller
> Fix For: 2.2
>
> Attachments: default-memory-options.patch
>
>
> It seems that the amount of PermGen space being used by Geronimo 2.2. I think 
> users are more likely to run into OutOfMemoryErrors as a result. Even on 
> small to medium size apps. Setting a default max heap and max perm size 
> should help avoid this...
> Looks like a 2.2 server is using the following:
> 50 MB heap
> 80 MB PermGen
> I'd suggest setting the max for both options to 128M. 

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

[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize


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

Quintin Beukes updated GERONIMO-4885:
-

Attachment: (was: default-memory-options.patch)

> Configure default max heap and max permsize
> ---
>
> Key: GERONIMO-4885
> URL: https://issues.apache.org/jira/browse/GERONIMO-4885
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: Kevan Miller
> Fix For: 2.2
>
>
> It seems that the amount of PermGen space being used by Geronimo 2.2. I think 
> users are more likely to run into OutOfMemoryErrors as a result. Even on 
> small to medium size apps. Setting a default max heap and max perm size 
> should help avoid this...
> Looks like a 2.2 server is using the following:
> 50 MB heap
> 80 MB PermGen
> I'd suggest setting the max for both options to 128M. 

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

[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize


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

Quintin Beukes updated GERONIMO-4885:
-

Attachment: default-memory-options.patch

Also updates the etc/rc.d/start-server,default.groovy to put the permgen=128m 
default to a Java5 execution.

> Configure default max heap and max permsize
> ---
>
> Key: GERONIMO-4885
> URL: https://issues.apache.org/jira/browse/GERONIMO-4885
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: Kevan Miller
> Fix For: 2.2
>
> Attachments: default-memory-options.patch
>
>
> It seems that the amount of PermGen space being used by Geronimo 2.2. I think 
> users are more likely to run into OutOfMemoryErrors as a result. Even on 
> small to medium size apps. Setting a default max heap and max perm size 
> should help avoid this...
> Looks like a 2.2 server is using the following:
> 50 MB heap
> 80 MB PermGen
> I'd suggest setting the max for both options to 128M. 

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

[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize


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

Quintin Beukes updated GERONIMO-4885:
-

Attachment: (was: default-memory-options.patch)

> Configure default max heap and max permsize
> ---
>
> Key: GERONIMO-4885
> URL: https://issues.apache.org/jira/browse/GERONIMO-4885
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: Kevan Miller
> Fix For: 2.2
>
>
> It seems that the amount of PermGen space being used by Geronimo 2.2. I think 
> users are more likely to run into OutOfMemoryErrors as a result. Even on 
> small to medium size apps. Setting a default max heap and max perm size 
> should help avoid this...
> Looks like a 2.2 server is using the following:
> 50 MB heap
> 80 MB PermGen
> I'd suggest setting the max for both options to 128M. 

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

[jira] Updated: (GERONIMO-4885) Configure default max heap and max permsize


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

Quintin Beukes updated GERONIMO-4885:
-

Attachment: default-memory-options.patch

The patch is for both the geronimo.bat and geronimo.sh and sets 
JAVA_OPTS="-Xmx128m -XX:MaxPermSize=128m" if JAVA_OPTS is empty/unset. Does so 
after setJavaEnv.bat and setjavaenv.sh has been callled (respectively).

> Configure default max heap and max permsize
> ---
>
> Key: GERONIMO-4885
> URL: https://issues.apache.org/jira/browse/GERONIMO-4885
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: Kevan Miller
> Fix For: 2.2
>
> Attachments: default-memory-options.patch
>
>
> It seems that the amount of PermGen space being used by Geronimo 2.2. I think 
> users are more likely to run into OutOfMemoryErrors as a result. Even on 
> small to medium size apps. Setting a default max heap and max perm size 
> should help avoid this...
> Looks like a 2.2 server is using the following:
> 50 MB heap
> 80 MB PermGen
> I'd suggest setting the max for both options to 128M. 

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

[jira] Commented: (GERONIMO-4871) Something blocking 'kill -3' signals?


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

Quintin Beukes commented on GERONIMO-4871:
--

Works for me on Ubuntu 8.04 with Java6 as well (also started with "sudo 
geronimo.sh start").

> Something blocking 'kill -3' signals?
> -
>
> Key: GERONIMO-4871
> URL: https://issues.apache.org/jira/browse/GERONIMO-4871
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Kevan Miller
> Fix For: 2.2
>
>
> I occasionally use 'kill -3' to cause a java process to dump all thread 
> stacks. For some reason, this isn't working on Geronimo 2.2

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

Re: Building only an assembly and what changed

2009-10-12 Thread Quintin Beukes

Hey,

Yes. I do build the kernel before the boilerplate, and that does help
get it into the boilerplate. Thanks.

Though, let me rephrase. I'm missing what step is needed to get the
assembly to use the new geronimo-kernel.jar, because it doesn't seem
to take it even if the boilerplate's .car file has my changes in it
(ie. 
framework/configs/geronimo-boilerplate/target/geronimo-boilerplate-2.2-SNAPSHOT.car
or something). I can get this right with an "mvn clean install",
though that seem redundant as well since there has to be a way to do
an incremental build when changing only certain parts of the code.

Quintin Beukes



On Mon, Oct 12, 2009 at 8:42 AM, Ivan  wrote:
> While compiling the geronimo-kernel module, do you run it with "mvn
> install", so that the geronimo-kernel jar file could be installed to the
> local repository. Or geronimo-boilerplate module could not package the
> latest jar file.
> Wish it helps !
>
> 2009/10/11 Quintin Beukes 
>>
>> I eventually settled on copying the geronimo-kernel JAR to an
>> extracted assembly.
>>
>> When I check the boilerplate/target/contents/lib/geronimo-kernel JAR,
>> it DOES have my code, in fact, that's the one I copied into my
>> extracted assembly.
>>
>> But I looked throughout the documentation, and tried reading the POMs
>> but can't find a way to build it other than a complete "mvn clean
>> install", which takes ages.
>>
>> I also tried doing a a -Dstage=assembly, which didn't help either.
>>
>> Would still like to know of a way to construct a clean assembly after
>> making change to the kernel.
>>
>> Quintin Beukes
>>
>>
>>
>> On Sun, Oct 11, 2009 at 1:25 PM, Quintin Beukes 
>> wrote:
>> > I'm doing something wrong, or there is another step.
>> >
>> > I rebuild the boilerplate config, and check in it's target/ directory
>> > inside the boilerplate car archive. My changed class is there, with
>> > the changes.
>> >
>> > Then I "cd {buildroot}/assemblies/geronimo-jetty7-javaee" and do "mvn
>> > install". It builds the assembly, but the ZIP it builds doesn't
>> > contain the boilerplate I just build.
>> >
>> > Quintin Beukes
>> >
>> >
>> >
>> > On Fri, Oct 9, 2009 at 7:06 PM, David Jencks 
>> > wrote:
>> >>
>> >> On Oct 9, 2009, at 7:55 AM, Quintin Beukes wrote:
>> >>
>> >>> Hey,
>> >>>
>> >>> Assume I change a .java file in the framework/modules/geronimo-kernel
>> >>> project, how can I easily only build what was changed and reassemble
>> >>> the zip for installing+running?
>> >>
>> >> There a few modules that are not put into the geronimo repository
>> >> structure
>> >> -- geronimo-kernel, geronimo-system, and a few others.  For these you
>> >> have
>> >> to rebuild the framework/configs/geronimo-boilerplate config before
>> >> rebuilding the assembly you want.
>> >>
>> >> Also, if you change anything related to a GBeanInfo -- for instance
>> >> attributes, operations, constructor parameters -- you have to rebuild
>> >> any
>> >> configs that might use that gbean.
>> >>
>> >> Otherwise, if you change code you can just rebuild the module and
>> >> rebuild
>> >> the assembly.  Or, if you want to live dangerously, you can just copy
>> >> the
>> >> new jar over the old one in the geronimo repo.
>> >>
>> >> thanks
>> >> david jencks
>> >>
>> >>>
>> >>> Quintin Beukes
>> >>
>> >>
>> >
>
>
>
> --
> Ivan
>

[jira] Updated: (GERONIMO-4903) Jetty Advanced Integration Test Failure

2009-10-12 Thread Quintin Beukes (JIRA)


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

Quintin Beukes updated GERONIMO-4903:
-

Attachment: jetty-advanced-test-failure.patch

attached the patch to fix the issue

> Jetty Advanced Integration Test Failure
> ---
>
> Key: GERONIMO-4903
> URL: https://issues.apache.org/jira/browse/GERONIMO-4903
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector
>    Reporter: Quintin Beukes
> Fix For: 2.2
>
> Attachments: jetty-advanced-test-failure.patch
>
>
> Hey,
> I found the cause of the test failure.
> In the file: {src
> root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
> Line: 289
> It reads: new String[]{"host", "port", "minThreads", "maxThreads",
> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
> "lingerMillis", "protocol", "redirectPort", "connectUrl",
> "maxIdleTimeMs"},
> Change to: new String[]{"host", "port", "minThreads", "maxThreads",
> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
> "lingerMillis", "redirectPort", "maxIdleTimeMs"},
> Basically removing the "protocol" and "connectUrl" attributes from the
> persistent interface attributes fixes the problem.
> "protocol" is static for Jetty BIO connector, so it doesn't need to be
> saved, or can't be specified.
> "connectUrl" is generated on the fly through getConnectUrl(), so can't
> be saved either.
> So unless my understanding of what persistentAttributes are is
> incorrect, this seems to be the correct solution? Please correct me if
> I'm wrong.
> What caused the problem is that the JettyConnector class doesn't have
> a setter for these attributes, so when XBean searches all the
> specified attributes' setters, it fails when it can't find these. This
> caused the test to fail, because the connector doesn't start again
> after being edited (enters the failed state).

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

[jira] Created: (GERONIMO-4903) Jetty Advanced Integration Test Failure

2009-10-12 Thread Quintin Beukes (JIRA)

Jetty Advanced Integration Test Failure
---

 Key: GERONIMO-4903
 URL: https://issues.apache.org/jira/browse/GERONIMO-4903
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: connector
Reporter: Quintin Beukes
 Fix For: 2.2
 Attachments: jetty-advanced-test-failure.patch

Hey,

I found the cause of the test failure.

In the file: {src
root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
Line: 289

It reads: new String[]{"host", "port", "minThreads", "maxThreads",
"bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
"lingerMillis", "protocol", "redirectPort", "connectUrl",
"maxIdleTimeMs"},
Change to: new String[]{"host", "port", "minThreads", "maxThreads",
"bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
"lingerMillis", "redirectPort", "maxIdleTimeMs"},

Basically removing the "protocol" and "connectUrl" attributes from the
persistent interface attributes fixes the problem.

"protocol" is static for Jetty BIO connector, so it doesn't need to be
saved, or can't be specified.
"connectUrl" is generated on the fly through getConnectUrl(), so can't
be saved either.

So unless my understanding of what persistentAttributes are is
incorrect, this seems to be the correct solution? Please correct me if
I'm wrong.

What caused the problem is that the JettyConnector class doesn't have
a setter for these attributes, so when XBean searches all the
specified attributes' setters, it fails when it can't find these. This
caused the test to fail, because the connector doesn't start again
after being edited (enters the failed state).


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

Re: Jetty Advanced Integration Test Failure

2009-10-12 Thread Quintin Beukes

No problem.

Quintin Beukes



On Mon, Oct 12, 2009 at 8:18 AM, Ivan  wrote:
> Thanks, Quinitin Beukes, could ypu please open a JIRA for it ? and if
> possible, attach your diff file to the JIRA.
>
> 2009/10/12 Quintin Beukes 
>>
>> Hey,
>>
>> I found the cause of the test failure.
>>
>> In the file: {src
>>
>> root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
>> Line: 289
>>
>> It reads: new String[]{"host", "port", "minThreads", "maxThreads",
>> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
>> "lingerMillis", "protocol", "redirectPort", "connectUrl",
>> "maxIdleTimeMs"},
>> Change to: new String[]{"host", "port", "minThreads", "maxThreads",
>> "bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
>> "lingerMillis", "redirectPort", "maxIdleTimeMs"},
>>
>> Basically removing the "protocol" and "connectUrl" attributes from the
>> persistent interface attributes fixes the problem.
>>
>> "protocol" is static for Jetty BIO connector, so it doesn't need to be
>> saved, or can't be specified.
>> "connectUrl" is generated on the fly through getConnectUrl(), so can't
>> be saved either.
>>
>> So unless my understanding of what persistentAttributes are is
>> incorrect, this seems to be the correct solution? Please correct me if
>> I'm wrong.
>>
>> What caused the problem is that the JettyConnector class doesn't have
>> a setter for these attributes, so when XBean searches all the
>> specified attributes' setters, it fails when it can't find these. This
>> caused the test to fail, because the connector doesn't start again
>> after being edited (enters the failed state).
>>
>> Quintin Beukes
>
>
>
> --
> Ivan
>

Jetty Advanced Integration Test Failure

2009-10-11 Thread Quintin Beukes

Hey,

I found the cause of the test failure.

In the file: {src
root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
Line: 289

It reads: new String[]{"host", "port", "minThreads", "maxThreads",
"bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
"lingerMillis", "protocol", "redirectPort", "connectUrl",
"maxIdleTimeMs"},
Change to: new String[]{"host", "port", "minThreads", "maxThreads",
"bufferSizeBytes", "headerBufferSizeBytes", "acceptQueueSize",
"lingerMillis", "redirectPort", "maxIdleTimeMs"},

Basically removing the "protocol" and "connectUrl" attributes from the
persistent interface attributes fixes the problem.

"protocol" is static for Jetty BIO connector, so it doesn't need to be
saved, or can't be specified.
"connectUrl" is generated on the fly through getConnectUrl(), so can't
be saved either.

So unless my understanding of what persistentAttributes are is
incorrect, this seems to be the correct solution? Please correct me if
I'm wrong.

What caused the problem is that the JettyConnector class doesn't have
a setter for these attributes, so when XBean searches all the
specified attributes' setters, it fails when it can't find these. This
caused the test to fail, because the connector doesn't start again
after being edited (enters the failed state).

Quintin Beukes

Re: Building only an assembly and what changed

2009-10-11 Thread Quintin Beukes

I eventually settled on copying the geronimo-kernel JAR to an
extracted assembly.

When I check the boilerplate/target/contents/lib/geronimo-kernel JAR,
it DOES have my code, in fact, that's the one I copied into my
extracted assembly.

But I looked throughout the documentation, and tried reading the POMs
but can't find a way to build it other than a complete "mvn clean
install", which takes ages.

I also tried doing a a -Dstage=assembly, which didn't help either.

Would still like to know of a way to construct a clean assembly after
making change to the kernel.

Quintin Beukes



On Sun, Oct 11, 2009 at 1:25 PM, Quintin Beukes  wrote:
> I'm doing something wrong, or there is another step.
>
> I rebuild the boilerplate config, and check in it's target/ directory
> inside the boilerplate car archive. My changed class is there, with
> the changes.
>
> Then I "cd {buildroot}/assemblies/geronimo-jetty7-javaee" and do "mvn
> install". It builds the assembly, but the ZIP it builds doesn't
> contain the boilerplate I just build.
>
> Quintin Beukes
>
>
>
> On Fri, Oct 9, 2009 at 7:06 PM, David Jencks  wrote:
>>
>> On Oct 9, 2009, at 7:55 AM, Quintin Beukes wrote:
>>
>>> Hey,
>>>
>>> Assume I change a .java file in the framework/modules/geronimo-kernel
>>> project, how can I easily only build what was changed and reassemble
>>> the zip for installing+running?
>>
>> There a few modules that are not put into the geronimo repository structure
>> -- geronimo-kernel, geronimo-system, and a few others.  For these you have
>> to rebuild the framework/configs/geronimo-boilerplate config before
>> rebuilding the assembly you want.
>>
>> Also, if you change anything related to a GBeanInfo -- for instance
>> attributes, operations, constructor parameters -- you have to rebuild any
>> configs that might use that gbean.
>>
>> Otherwise, if you change code you can just rebuild the module and rebuild
>> the assembly.  Or, if you want to live dangerously, you can just copy the
>> new jar over the old one in the geronimo repo.
>>
>> thanks
>> david jencks
>>
>>>
>>> Quintin Beukes
>>
>>
>

Re: Building only an assembly and what changed

2009-10-11 Thread Quintin Beukes

I'm doing something wrong, or there is another step.

I rebuild the boilerplate config, and check in it's target/ directory
inside the boilerplate car archive. My changed class is there, with
the changes.

Then I "cd {buildroot}/assemblies/geronimo-jetty7-javaee" and do "mvn
install". It builds the assembly, but the ZIP it builds doesn't
contain the boilerplate I just build.

Quintin Beukes



On Fri, Oct 9, 2009 at 7:06 PM, David Jencks  wrote:
>
> On Oct 9, 2009, at 7:55 AM, Quintin Beukes wrote:
>
>> Hey,
>>
>> Assume I change a .java file in the framework/modules/geronimo-kernel
>> project, how can I easily only build what was changed and reassemble
>> the zip for installing+running?
>
> There a few modules that are not put into the geronimo repository structure
> -- geronimo-kernel, geronimo-system, and a few others.  For these you have
> to rebuild the framework/configs/geronimo-boilerplate config before
> rebuilding the assembly you want.
>
> Also, if you change anything related to a GBeanInfo -- for instance
> attributes, operations, constructor parameters -- you have to rebuild any
> configs that might use that gbean.
>
> Otherwise, if you change code you can just rebuild the module and rebuild
> the assembly.  Or, if you want to live dangerously, you can just copy the
> new jar over the old one in the geronimo repo.
>
> thanks
> david jencks
>
>>
>> Quintin Beukes
>
>

Re: Building only an assembly and what changed

2009-10-09 Thread Quintin Beukes

> Also, if you change anything related to a GBeanInfo -- for instance
> attributes, operations, constructor parameters -- you have to rebuild any
> configs that might use that gbean.
>

Just to check this, if I just add System.out.println() to one of the
GBeanInfo methods I don't have to rebuild the configs right? Only if I
change the class in such a way that a deserialize will fail, ie. any
new fields/methods/etc?

Q

Re: TestSuite Assembly Installation

2009-10-09 Thread Quintin Beukes

This is how I am doing it, though it still extracts and attempts to
start the server. This one just fails because of the a port conflict,
but when the maven plugin checks if the server is present, the already
running server makes this check succeed, and everything can continue.

I am wondering about that extract part specifically, if I can skip
that step as well.

If someone can just give me an idea about how this is achieved, I'll
investigate further and temporarily modify whatever is needed to get
this done.

Quintin Beukes

On Fri, Oct 9, 2009 at 7:03 PM, David Jencks  wrote:
>
> On Oct 9, 2009, at 6:33 AM, Quintin Beukes wrote:
>
>> Hey,
>>
>> How can I disable the installation/expanding of the assembly zip?
>>
>> I just run the server concurrently to make the test run faster.
>
> IIRC, if you have started a server independently, you can run a part of the
> testsuite just by cd'ing to the appropriate directory containing the
> testsuite bits and running mvn clean install.
>
> thanks
> david jencks
>
>>
>> It's not a big deal, but it could sure speed up another 10 or so seconds.
>>
>> Quintin Beukes
>
>

Re: With Latest G2.2 svn build (rev 816446) can't start through "gsh"

2009-10-09 Thread Quintin Beukes

This problem seems to be gone now. thanks.

Quintin Beukes



On Wed, Sep 23, 2009 at 11:08 AM, Quintin Beukes  wrote:
> Re. being up to date:
>
> URL: https://svn.apache.org/repos/asf/geronimo/server/branches/2.2
> Repository Root: https://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 816550
>
> Then, I did the full build of all artifacts, ie. from the root typed:
> mvn install
>
> Quintin Beukes
>
>
>
> On Wed, Sep 23, 2009 at 11:07 AM, Quintin Beukes  
> wrote:
>> Environment is linux. Where would this "replacement" happen. I can
>> have a look at it.
>>
>> Quintin Beukes
>>
>>
>>
>> On Wed, Sep 23, 2009 at 7:26 AM, David Jencks  wrote:
>>> I fixed this problem once recently, and no longer see it on my mac.  Are you
>>> sure the source is up to date with svn?  What environment does the problem
>>> happen in?
>>>
>>> thanks
>>> david jencks
>>>
>>> On Sep 22, 2009, at 8:41 PM, Forrest_Xia wrote:
>>>
>>>>
>>>> For some reason, Geronimo build system does not replace {$version} with
>>>> 2.2-SNAPSHOT in GShell configuration file, that cause the problem.
>>>>
>>>> Anyway, it seems just happens on local build, not on server build. If
>>>> someone in charge of building system could see this problem, that would be
>>>> appreciated!
>>>>
>>>> Forrest
>>>>
>>>>
>>>> Q Beukes wrote:
>>>>>
>>>>> Hey,
>>>>>
>>>>> I have the G2.2 branch rev 816446 build, but can't start through gsh
>>>>> geronimo/start-server anymore. I confirmed and it's still working on
>>>>> previous builds. So it's not a system configuration problem as far as
>>>>> I can see.
>>>>>
>>>>> This is what I'm getting:
>>>>> quin...@quintin-desktop bin $ sudo ./gsh --verbose --debug -c
>>>>> "geronimo/start-server"
>>>>> org.codehaus.plexus.classworlds.launcher.ConfigurationException: No
>>>>> such property: version
>>>>>       at
>>>>>
>>>>> org.codehaus.plexus.classworlds.launcher.Configurator.filter(Configurator.java:574)
>>>>>       at
>>>>>
>>>>> org.codehaus.plexus.classworlds.launcher.Configurator.configure(Configurator.java:311)
>>>>>       at
>>>>>
>>>>> org.codehaus.plexus.classworlds.launcher.Launcher.configure(Launcher.java:131)
>>>>>       at
>>>>>
>>>>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:404)
>>>>>       at
>>>>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
>>>>>       at
>>>>> org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
>>>>>
>>>>> Quintin Beukes
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/With-Latest-G2.2-svn-build-%28rev-816446%29-can%27t-start-through-%22gsh%22-tp25514949s134p25530978.html
>>>> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>
>

console-testsuite/advanced failure on WebServerTest.testEditConnector

2009-10-09 Thread Quintin Beukes

 at 
org.apache.geronimo.jetty7.handler.JaccSecurityHandler.handle(JaccSecurityHandler.java:89)
at 
org.eclipse.jetty.server.session.SessionHandler.handle(SessionHandler.java:179)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:930)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:361)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:864)
at 
org.apache.geronimo.jetty7.handler.GeronimoWebAppContext.doScope(GeronimoWebAppContext.java:107)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:116)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:243)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:112)
at org.eclipse.jetty.server.Server.handle(Server.java:333)
at 
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:552)
at 
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:993)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:739)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:209)
at 
org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:399)
at 
org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:437)
at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
at 
org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)

Another time it also failed with:
org.apache.xbean.recipe.MissingAccessorException: Unable to find a
valid setter method: public void
org.apache.geronimo.jetty7.connector.HTTPSelectChannelConnector.setProtocol(...)

I'm not sure I did anything different. I just figure it was sorted a
bit differently. So it seems like it could be those 2 properties for
which it doesn't have setters.

I had a look at JettyConnector, and noticed there is a
getConnectUrl(), which dynamically constructs it from the relevant
parts, though there isn't a setConnectUrl(). Same with getProtocol()
which returns a static value. I tried to look around the stacktrace to
see if I can find where they come from, but was unable to do so,
mainly due to not being able to have my changes reflect in Geronimo.
In 
./framework/modules/geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/GBeanInstance.java
where it creates the ObjectRecipe I added a System.out.println() to
see which properties are being supplied (in order to learn what's
going on where and how it works), but I tried many different compiles
and can't seem to get those values to ever print anywhere.

So, I have 2 questions.
1. Can someone please tell me how to build a given section of
geronimo. A complete build even with tests disabled takes FAR too
long.
2. Re. these methods.
- I can try and trace where the properties come from and maybe have
them not sent through to these classes, so they don't try to get
injected.
- OR, I can add a dummy setter for setProtocol() which simply ignores
the String supplied to it, and a setConnectUrl() which breaks up the
string and sets the components (the reverse of getConnectUrl()).

Quintin Beukes

Building only an assembly and what changed

2009-10-09 Thread Quintin Beukes

Hey,

Assume I change a .java file in the framework/modules/geronimo-kernel
project, how can I easily only build what was changed and reassemble
the zip for installing+running?

Quintin Beukes

TestSuite Assembly Installation

2009-10-09 Thread Quintin Beukes

Hey,

How can I disable the installation/expanding of the assembly zip?

I just run the server concurrently to make the test run faster.

It's not a big deal, but it could sure speed up another 10 or so seconds.

Quintin Beukes

Running Geronimo 2.2 SNAPSHOT Testsuite

2009-10-06 Thread Quintin Beukes

Hey,

When I run the testsuite with "mvn install", I get the following:
[WARNING] OS appears to be Unix and no DISPLAY environment variable
has been detected. Browser maybe unable to function correctly.
Consider using the selenium:xvfb goal to enable headless operation.

I have been unable to get the tests to pass the same as reported by
the gawor mails. Am trying another build+test with JDK5, and will see
how that turns out later.

Could this cause warning tests to fail? I am running it over an "ssh"
and "screen" session, so there is definitely no display, though if a
display is needed, I'd do it via vnc.

Quintin Beukes

Re: OSGI progress

2009-09-24 Thread Quintin Beukes

I learned OSGi while implementing Felix. Was a good place to start.
The Felix docs wasn't that good in introducing OSGi (at the time at
least) and consisted mostly of example tutorials on implementing the
basic OSGi models, though a little bit of logical thought with them
got me into starting an OSGi based application in little under an
hour.

Further, try reading the docs on the OSGi alliance web site. IIRC
there were some OSGi introductions that weren't as involved as the
spec itself, which helped clear up some questions I had during this
development.

You could give these a try.

Quintin Beukes

On Wed, Sep 23, 2009 at 11:39 PM, Jay D. McHugh  wrote:
> So it sounds like I can't put off learning OSGi anymore :)
>
> Does anyone have suggested resources (books, websites, or tutorials)
> that they found useful?
>
> Thanks in advance,
>
> Jay
>
> David Jencks wrote:
>> Over the weekend I got my sandbox osgi framework to build and generate
>> all the plugins as osgi bundles.  This involves running some of the
>> geronimo server on osgi/felix inside maven.  The dependency management
>> system seems to work OK at least for starting bundles.  I also started
>> doing a little bit of code cleanup.
>>
>> I think the next step will be to get the framework server running in
>> standalone karaf or felix.  Hopefully this will be no harder than
>> getting it running in embedded felix in maven.
>>
>> thanks
>> david jencks
>>
>

Re: 2.2 progress

2009-09-23 Thread Quintin Beukes

If the update/review of the LICENSE/NOTICE information is a lot of
work, send some my way if it will help release some of the developer's
time for more important tasks.

Quintin Beukes



On Wed, Sep 23, 2009 at 4:39 PM, Kevan Miller  wrote:
>
> On Sep 21, 2009, at 8:21 PM, David Jencks wrote:
>
>> I think things are moving along for 2.2.
>>
>> - our last internal dependency, the tomcat fork, seems to have passed its
>> vote, although I'd prefer it if Kevan would take a look.
>>
>> - ActiveMQ is pushing release candidates.  The first one showed no tck
>> problems in geronimo.
>>
>> - OpenEJB IIUC is pretty much ready to release.
>
> It looks like OpenEJB has an SFSB problem, which will need to be fixed
> before they release a 3.1.2.
>
>>
>> ---
>>
>> Stuff to do:
>>
>> - tranql has been getting some attention lately.  We should try to find a
>> jdbc expert verify the list of non-fatal SQLCodes.  I would like to
>> rearrange tranql svn, but otherwise I'm OK with the code for now.  After we
>> verify stuff works I can release this.
>
> This would be really good, IMO. Will see if I can find somebody to help
> review the SQLCodes.
>
>>
>> - We have a pluto fix that I'm hoping we can duplicate in geronimo
>> somehow.  IIRC we have a couple of pluto driver classes replaced in geronimo
>> already, I hope we can do the same with this pluto fix.  Pushing a pluto 1.x
>> release could be difficult.
>>
>> - We don't know yet whether the maven release plugin and apache-release
>> profile will work with geronimo.
>>
>> - review the jiras carefully.
>
> - update / review LICENSE & NOTICE information.
>
> --kevan
>

Re: With Latest G2.2 svn build (rev 816446) can't start through "gsh"

2009-09-23 Thread Quintin Beukes

Re. being up to date:

URL: https://svn.apache.org/repos/asf/geronimo/server/branches/2.2
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 816550

Then, I did the full build of all artifacts, ie. from the root typed:
mvn install

Quintin Beukes



On Wed, Sep 23, 2009 at 11:07 AM, Quintin Beukes  wrote:
> Environment is linux. Where would this "replacement" happen. I can
> have a look at it.
>
> Quintin Beukes
>
>
>
> On Wed, Sep 23, 2009 at 7:26 AM, David Jencks  wrote:
>> I fixed this problem once recently, and no longer see it on my mac.  Are you
>> sure the source is up to date with svn?  What environment does the problem
>> happen in?
>>
>> thanks
>> david jencks
>>
>> On Sep 22, 2009, at 8:41 PM, Forrest_Xia wrote:
>>
>>>
>>> For some reason, Geronimo build system does not replace {$version} with
>>> 2.2-SNAPSHOT in GShell configuration file, that cause the problem.
>>>
>>> Anyway, it seems just happens on local build, not on server build. If
>>> someone in charge of building system could see this problem, that would be
>>> appreciated!
>>>
>>> Forrest
>>>
>>>
>>> Q Beukes wrote:
>>>>
>>>> Hey,
>>>>
>>>> I have the G2.2 branch rev 816446 build, but can't start through gsh
>>>> geronimo/start-server anymore. I confirmed and it's still working on
>>>> previous builds. So it's not a system configuration problem as far as
>>>> I can see.
>>>>
>>>> This is what I'm getting:
>>>> quin...@quintin-desktop bin $ sudo ./gsh --verbose --debug -c
>>>> "geronimo/start-server"
>>>> org.codehaus.plexus.classworlds.launcher.ConfigurationException: No
>>>> such property: version
>>>>       at
>>>>
>>>> org.codehaus.plexus.classworlds.launcher.Configurator.filter(Configurator.java:574)
>>>>       at
>>>>
>>>> org.codehaus.plexus.classworlds.launcher.Configurator.configure(Configurator.java:311)
>>>>       at
>>>>
>>>> org.codehaus.plexus.classworlds.launcher.Launcher.configure(Launcher.java:131)
>>>>       at
>>>>
>>>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:404)
>>>>       at
>>>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
>>>>       at
>>>> org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
>>>>
>>>> Quintin Beukes
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/With-Latest-G2.2-svn-build-%28rev-816446%29-can%27t-start-through-%22gsh%22-tp25514949s134p25530978.html
>>> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>

Re: With Latest G2.2 svn build (rev 816446) can't start through "gsh"

2009-09-23 Thread Quintin Beukes

Environment is linux. Where would this "replacement" happen. I can
have a look at it.

Quintin Beukes



On Wed, Sep 23, 2009 at 7:26 AM, David Jencks  wrote:
> I fixed this problem once recently, and no longer see it on my mac.  Are you
> sure the source is up to date with svn?  What environment does the problem
> happen in?
>
> thanks
> david jencks
>
> On Sep 22, 2009, at 8:41 PM, Forrest_Xia wrote:
>
>>
>> For some reason, Geronimo build system does not replace {$version} with
>> 2.2-SNAPSHOT in GShell configuration file, that cause the problem.
>>
>> Anyway, it seems just happens on local build, not on server build. If
>> someone in charge of building system could see this problem, that would be
>> appreciated!
>>
>> Forrest
>>
>>
>> Q Beukes wrote:
>>>
>>> Hey,
>>>
>>> I have the G2.2 branch rev 816446 build, but can't start through gsh
>>> geronimo/start-server anymore. I confirmed and it's still working on
>>> previous builds. So it's not a system configuration problem as far as
>>> I can see.
>>>
>>> This is what I'm getting:
>>> quin...@quintin-desktop bin $ sudo ./gsh --verbose --debug -c
>>> "geronimo/start-server"
>>> org.codehaus.plexus.classworlds.launcher.ConfigurationException: No
>>> such property: version
>>>       at
>>>
>>> org.codehaus.plexus.classworlds.launcher.Configurator.filter(Configurator.java:574)
>>>       at
>>>
>>> org.codehaus.plexus.classworlds.launcher.Configurator.configure(Configurator.java:311)
>>>       at
>>>
>>> org.codehaus.plexus.classworlds.launcher.Launcher.configure(Launcher.java:131)
>>>       at
>>>
>>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:404)
>>>       at
>>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
>>>       at
>>> org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
>>>
>>> Quintin Beukes
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/With-Latest-G2.2-svn-build-%28rev-816446%29-can%27t-start-through-%22gsh%22-tp25514949s134p25530978.html
>> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
>>
>
>

Re: OSGI progress

2009-09-23 Thread Quintin Beukes

>>
>>
>>    What I mean is that, currently, Geronimo kernel is running in the OSGI
>> environment, and all those GBeans are running in the kernel.  I would like
>> to see that the OSGI is Geronimo kernel.  As you said in the comments below,
>> we might not need a kernel at all :-)
>>
> Yes. I hope so.
>

I'm trying to follow what you guys are saying, because it sounds very
interesting. I might be misunderstanding what the Geronimo Kernel is
exactly. If I understand this correctly, ie. the kernel provides
services, won't it make it difficult to then "replace" the kernel? If
the kernel is a bundle, it can be uninstalled/reinstalled, and provide
it's services? Similar to other OSGi environments, ex. Eclipse IDE.
The OSGi environment loads the IDE core as a bundle. Eclipse IDE core
isn't the OSGi. The actual "OSGi" in OSGi implementations is merely
the engine for managing/loading/activating bundles and services, and
if you keep to the spec should be nothing more than this?

Q

With Latest G2.2 svn build (rev 816446) can't start through "gsh"

2009-09-18 Thread Quintin Beukes

Hey,

I have the G2.2 branch rev 816446 build, but can't start through gsh
geronimo/start-server anymore. I confirmed and it's still working on
previous builds. So it's not a system configuration problem as far as
I can see.

This is what I'm getting:
quin...@quintin-desktop bin $ sudo ./gsh --verbose --debug -c
"geronimo/start-server"
org.codehaus.plexus.classworlds.launcher.ConfigurationException: No
such property: version
at 
org.codehaus.plexus.classworlds.launcher.Configurator.filter(Configurator.java:574)
at 
org.codehaus.plexus.classworlds.launcher.Configurator.configure(Configurator.java:311)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.configure(Launcher.java:131)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:404)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)

Quintin Beukes

Re: The setting of LoginDomainName attribute of the LoginModuleGBean

2009-09-14 Thread Quintin Beukes

For interest sake, how would you use this to implement the below?

If you have a doc specifying this, can you send me the link. This
explanation made it sound interesting, as I myself have wondered about
the WrappingLoginModule.

Q

On Mon, Sep 14, 2009 at 6:42 PM, David Jencks  wrote:
>
> On Sep 14, 2009, at 12:51 AM, Ivan wrote:
>
>> Hi
>>  In the LoginModuleGBean, there is an attribute named loginDomainName, I
>> went through the codes, just found that while the WrappingLoginModule is
>> turned on, those domainNames are used in the Subject as DomainPrincipal.
>> Except for this, is there any use for those loginDomainNames ? And, I did
>> not found any example for WrappingLoginModule, so when we would use it ?
>>  Thanks !
>
> I thought this was documented somewhere, but I could easily be wrong, and
> the explanation might not include enough info for anyone to know why...
>
> Most people use the simplest form of principal-role mapping, where you
> specify the class and name of the actual Principal from the login module you
> specify.  However, it's possible to think up more complicated scenarios
> where this is not enough to identify the principal for the principal-role
> mapping.
>
> lets suppose you have an ejb app C with 2 web apps A and B in front of it.
>  Your ejb app has 2 roles r1 and r2.  You have two legacy security systems
> S1 and S2 with proprietary login modules that both happen to supply the same
> principal class.  You need to use S1 with A and S2 with B.  S1 and S2 both
> provide principals with names "g1" and "g2" but the meaning is opposite.
> you need
>
> For S1 and A,
> "g1" > r1
> "g2" > r2
>
> but for S2 and B,
> "g1" > r2
> "g2" > r1
>
> So, you need more information to distinguish the principals so you can map
> them to the correct roles.  Geronimo lets you wrap the original principals
> with a wrapper that contains a name of the login module "loginDomainName"
> and the name of the security realm, and the principal-role mapping can
> specify these as well.  You'd use the loginDomainName if you set up a single
> security realm that includes the login modules for S1 and S2, and the
> security realm if you set up two separate security realms.
>
> I don't know if anyone has used this or ever will, but we thought we'd be
> thorough.
>
> thanks
> david jencks
>
>> --
>> Ivan
>
>



-- 
Quintin Beukes

Re: There's still hope for 2.2...

2009-09-11 Thread Quintin Beukes

There are some bugs I reported regarding adding/removing connectors. I
seriously think they need to be addressed. They are:
https://issues.apache.org/jira/browse/GERONIMO-4867
https://issues.apache.org/jira/browse/OPENEJB-1070
https://issues.apache.org/jira/browse/GERONIMO-4860
https://issues.apache.org/jira/browse/GERONIMO-4861

The last one is a regression of sorts (in other words is wasn't present in 2.1).

They're all small errors, and I listed them because they can
potentially damage Geronimo's image by complicating a user's
experience. User experience is the biggest factor in a product's
success.

Q

On Fri, Sep 11, 2009 at 11:49 AM, Ivan  wrote:
> Sorry, I make a mistaken, I did not mean
> https://issues.apache.org/jira/browse/GERONIMO-4603, I mean GERONIMO-4625
>
>
> 2009/9/11 Ivan 
>>
>> I wish those JIRAs to be included in Geronimo 2.2
>>
>> https://issues.apache.org/jira/browse/GERONIMO-4801
>> Please check my comment, I think we could just ignore the alreadyexisted
>> exception
>>
>> https://issues.apache.org/jira/browse/GERONIMO-4821
>> Please check my comment, I need more help on it :-(
>>
>> https://issues.apache.org/jira/browse/GERONIMO-4836
>> If anyone could help to check the patch in the current pluto snapshot,
>> that will be fine. or, I wish to fix it in Geronimo 2.2 firstly
>>
>> https://issues.apache.org/jira/browse/GERONIMO-4493
>> I am working on it, and it will be finished soon
>>
>> https://issues.apache.org/jira/browse/GERONIMO-4603
>> I am working on it, and it will be finished soon
>>
>> Thanks !
>>
>> 2009/9/11 David Jencks 
>>>
>>> We may be able to release 2.2 soon.  Activemq has fixed the last bug we
>>> had problems with and is fast approaching a release, openejb is getting very
>>> close to a release for 2.2, and I've started votes on a number of our
>>> snapshot dependencies.
>>>
>>> At this point I'd like anyone who is working on something they'd like to
>>> get into 2.2 to reply to this with a description of what they are working on
>>> and an estimate for completion.
>>>
>>> Also, if there is something you think is really necessary to get into 2.2
>>> please reply and describe what you'd like.
>>>
>>> many thanks
>>> david jencks
>>>
>>
>>
>>
>> --
>> Ivan
>
>
>
> --
> Ivan
>



-- 
Quintin Beukes

[jira] Updated: (GERONIMO-4861) Deployment Plan XML Parsing - Not add generated namespace names to closing tags

2009-09-11 Thread Quintin Beukes (JIRA)


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

Quintin Beukes updated GERONIMO-4861:
-

Regression: [Regression]

> Deployment Plan XML Parsing - Not add generated namespace names to closing 
> tags
> ---
>
> Key: GERONIMO-4861
> URL: https://issues.apache.org/jira/browse/GERONIMO-4861
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.2
>Reporter: Quintin Beukes
>Priority: Minor
>
> When creating a deployment plan and using more than one namespace, but not 
> implicitly specifying the namespaces in all elements, the namespace names are 
> added to the temporary XML file. Though it doesn't add them correctly. I 
> included my original openejb-jar.xml, the error I get through deploy.sh, and 
> the generated XML file (which I reformatted to make it more readable). 
> You will notice the problem are in the last 2 closing tags of the ns7 (ie. 
> security-2.0) namespace. The ns7 namespace prefix wasn't added to them, and 
> this generates the validator error.
> {code:xml|title=original-openejb-jar.xml}
> 
> http://openejb.apache.org/xml/ns/openejb-jar-2.2";
>  xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
>  xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0";
>  xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";>
>   
> 
>   kms
>   KMSPlatform-ejb
>   1.0
>   jar
> 
> 
>   
> console.dbpool
> jdbc_kmsPool
> 1.0
> rar
>   
>   
> console.realm
> KMSRealm
> 1.0
> car
>   
>   
> org.springframework
> spring-core
> 2.5.6
> jar
>   
>   
> org.springframework
> spring-beans
> 2.5.6
> jar
>   
>   
> org.springframework
> spring-context
> 2.5.6
> jar
>   
>   
> org.slf4j
> slf4j-api
> 1.5.5
> jar
>   
>   
>   
> hibernate
> core
> 3.3
> jar
>   
>   
> hibernate
> annotations
> 3.4
> jar
>   
>   
> hibernate
> antlr
> 2.7.6
> jar
>   
>   
> hibernate
> commons-annotations
> 3.4
> jar
>   
>   
> hibernate
> commons-collections
> 3.1
> jar
>   
>   
> hibernate
> dom4j
> 1.6.1
> jar
>   
>   
> hibernate
> entitymanager
> 3.4
> jar
>   
>   
> hibernate
> javassist
> 3.9.0.GA
> jar
>   
>   
> hibernate
> jpa
> 3.0
> jar
>   
>   
> hibernate
> jta
> 1.1
> jar
>   
>   
> hibernate
> GeronimoTransactionManager
> 1.0
> jar
>   
> 
>   
>   
> 
>   
>  class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>   name="Admin"/>
>   
>   
>  class="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>   name="Standard User"/>
>   
> 
>   
> 
> {code}
> {code:title=Deployment Error}
> 2009-09-10 11:43:04,602 ERROR [DeployTool] Error: 
> org.apache.geronimo.common.DeploymentException: Unable to deploy 
> KMSPlatform-ejb.jar: Error parsing geronimo-openejb.xml with xmlbeans.  
> For debug purposes, XML content written to: 
> /opt/kms/server/geronimo-2.2-20090908/var/temp/openejb-jar-1373120338936693638.xml
> error:  does not close tag .
>  does not close tag .
> at 
> org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:45)
> at 
> org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:149)
> at 
> org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:125)
> a

[jira] Created: (GERONIMO-4867) Compared to 2.1, 2.2 doesn't handle security realms created through the console the same

2009-09-11 Thread Quintin Beukes (JIRA)

Compared to 2.1, 2.2 doesn't handle security realms created through the console 
the same


 Key: GERONIMO-4867
 URL: https://issues.apache.org/jira/browse/GERONIMO-4867
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: console, security
Affects Versions: 2.2
Reporter: Quintin Beukes
 Fix For: 2.2


In 2.1, when adding a security realm through the console, they were created as 
Global realms. So you could log in via OpenEJB remotely without problems.

If you were to upgrade to 2.2, you can't continue doing this if you deploy the 
old realm file, because in 2.2 there is a "Global" parameter for a security 
realm which defaults to false. So "upgrading" to 2.2, means deploying the same 
application, and when doing this your application won't work if you use this 
functionality.

You would get a "No LoginModules defined for realm XXX" exception, which means 
the realm isn't found. 

So this would create problems for people.

I Suggest two options
1. If the global attribute is absent, default to "true"
2. When doing a remote login via OpenEJB, treat all realms as global. In other 
words a remote login as access to all realms. People upgrading will still get 
the same behaviour, and their old deploy plans will still allow their 
applications to work. This seems fine, because there isn't a way for you to 
define dependencies on a remote client anyway, so treating all realms as global 
seems fine. This might be considered bad practice, since the global attribute 
is meant to close of realms from other people.

Not really sure what the philosophies are around this, so I can't say which is 
best. I would personally prefer the first option, as it allows one to still 
isolate realms. And if you find that a realm is global, which you wouldn't have 
wanted so, it's as easy as redeploying it to fix it.

I definitely suggest that this be addressed before 2.2's release, as it will 
create bad first impressions. One should always provide for all scenarios to 
make the end user experience as comfortable as possible.


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

[jira] Created: (GERONIMO-4861) Deployment Plan XML Parsing - Not add generated namespace names to closing tags

Deployment Plan XML Parsing - Not add generated namespace names to closing tags
---

 Key: GERONIMO-4861
 URL: https://issues.apache.org/jira/browse/GERONIMO-4861
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 2.2
Reporter: Quintin Beukes
Priority: Minor


When creating a deployment plan and using more than one namespace, but not 
implicitly specifying the namespaces in all elements, the namespace names are 
added to the temporary XML file. Though it doesn't add them correctly. I 
included my original openejb-jar.xml, the error I get through deploy.sh, and 
the generated XML file (which I reformatted to make it more readable). 

You will notice the problem are in the last 2 closing tags of the ns7 (ie. 
security-2.0) namespace. The ns7 namespace prefix wasn't added to them, and 
this generates the validator error.

{code:xml|title=original-openejb-jar.xml}

http://openejb.apache.org/xml/ns/openejb-jar-2.2";
 xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
 xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0";
 xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";>

  

  kms
  KMSPlatform-ejb
  1.0
  jar



  
console.dbpool
jdbc_kmsPool
1.0
rar
  

  
console.realm
KMSRealm
1.0
car
  

  
org.springframework
spring-core
2.5.6
jar
  
  
org.springframework
spring-beans
2.5.6
jar
  
  
org.springframework
spring-context
2.5.6
jar
  

  
org.slf4j
slf4j-api
1.5.5
jar
  

  
  
hibernate
core
3.3
jar
  
  
hibernate
annotations
3.4
jar
  
  
hibernate
antlr
2.7.6
jar
  
  
hibernate
commons-annotations
3.4
jar
  
  
hibernate
commons-collections
3.1
jar
  
  
hibernate
dom4j
1.6.1
jar
  
  
hibernate
entitymanager
3.4
jar
  
  
hibernate
javassist
3.9.0.GA
jar
  
  
hibernate
jpa
3.0
jar
  
  
hibernate
jta
1.1
jar
  
  
hibernate
GeronimoTransactionManager
1.0
jar
  

  

  

  

  
  

  

  

{code}

{code:title=Deployment Error}
2009-09-10 11:43:04,602 ERROR [DeployTool] Error: 
org.apache.geronimo.common.DeploymentException: Unable to deploy 
KMSPlatform-ejb.jar: Error parsing geronimo-openejb.xml with xmlbeans.  
For debug purposes, XML content written to: 
/opt/kms/server/geronimo-2.2-20090908/var/temp/openejb-jar-1373120338936693638.xml
error:  does not close tag .
 does not close tag .

at 
org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:45)
at 
org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:149)
at 
org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:125)
at 
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:168)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at 
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
{code}

{code:xml|title=reformatted 
/opt/kms/server/geronimo-2.2-20090908/var/temp/openejb-jar-1373120338936693638.xml}

http://geronimo.apache.org/xml/ns/deployment-1.2"; 
xmlns:ns2="http://geronimo.apache.org/xml/ns/j2ee/application-1.2"; 
xmlns:ns3="http://geronimo.apache.org/xml/ns/openejb-clustering-wadi-1.2"; 
xmlns:ns4="http://geronimo.apache.org/xml/ns/naming-1.2"; 
xmlns:ns5="http://openejb.apache.org/xml/ns/openejb-jar-2.2"; 
xmlns:ns6="http://geronimo.apache.org/xml/ns/j2ee/ejb/openejb-2.0"; 
xmlns:ns7="http://geronimo.apache.org/xml/ns/security-2.0"; 
xmlns:ns8="http://java.sun.com/xml/ns/persistence"; 
xmlns:ns9="http://openejb.apache.org/xml/ns/pkgen-2.1";>
  

  kms
  KMSPlatform-ejb
  1.0
  jar


  
console.dbpool
jdbc_kmsPool
1.0
rar
  
  
consol

[jira] Updated: (GERONIMO-4848) Application Client Login Retries


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

Quintin Beukes updated GERONIMO-4848:
-

Attachment: OpenejbRemoteLoginModule.java-2.2
login-retries-2.2.patch

Geronimo 2.2 doesn't use Commons Logging anymore, so this is the same 
modification as above, except with the slf4j logger change applied.

>From 2.1.4 to 2.2 this file hasn't changed, so it should be fine to apply it.

Explanation: 
  OpenejbRemoteLoginModule.java-2.2 - a full .java for Geronimo 2.2
  login-retries-2.2.patch - A patch to transform Geronimo 2.2's login module 
adding the login-retries.

> Application Client Login Retries
> 
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: application client, security
>    Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries-2.2.patch, login-retries.patch, 
> OpenejbRemoteLoginModule.java, OpenejbRemoteLoginModule.java-2.2
>
>
> When an application client is configured to authenticate with a JAAS realm 
> and a CallbackHandler, the login is performed before the application's main 
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for 
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of 
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional 
> extra "option", which can be specified in the gbean configuration, like so:
> ...
> 
>   remote-openejb-realm
>   
> net.kunye.platform.security.auth.ApplicationClientLoginModule
>   KMSRealm
>   ejbd://localhost:4201
>   3
> 
> ...
> - If you omit this option, it will default to the current behaviour of "1" 
> try.
> - If you supply an invalid value for an option (any value that would raise a 
> NumberFormatException when calling "Integer.parseInt()"), it will default to 
> the current behaviour of "1" try.
> - If you specify an integer great or equal to 0, it will perform the given 
> amount of tries. If no successful authentication occurred during these tries 
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a 
> successful authentication or the user cancelled. The cancel is detected by 
> setting either the NameCallback or PasswordCallback's value to null. This is 
> quite unintuitive and might make it more difficult to find bugs in your code 
> where the values are unintentionally null, so an alternative way might be 
> better. 
> Note: The "cancel" check works for all logins, including the first try. 
> - Further, if a "cancel" is detected, the callback handler is invoked with a 
> single TextOutputCallback which contains an INFORMATION type message "Login 
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single 
> TextOutputCallback which contains an ERROR type message "Login failed for 
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the 
> application client is to have more direct access to the CallbackHandler, so 
> as to send the "Login Failed" and "Login canceled" messages. Also the fact 
> that certain types of login modules might be used which don't support the 
> "concept" of a retry, like host based authentication modules. So doing 
> retries in the application client layer didn't seem logical. This way you can 
> also extend the class or build your own and ship it with your application, 
> and so be able to customize the retry behaviour, instead of relying on a 
> fixed retry strategy in the application client layer (which could only be 
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Updated: (GERONIMO-4860) WebManagerPortlet doesn't complete remove a connector - leads to inability to start server


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

Quintin Beukes updated GERONIMO-4860:
-

Description: 
When removing a connector, it removes the connector from tomcat's server.xml, 
but not the GBean from config.xml, so when stopping and again start the server, 
the server fails to start with: 
{code:title=geronimo.log}2009-09-10 10:45:28,076 ERROR [GBeanInstanceState] 
Error while starting; GBean is now in the FAILED state: 
  
abstractName="org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car"
org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans must be 
specified with a GBeanInfo 
configuration=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car 
  
gbeanName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car,j2eeType=GBean,name=testConnector1
at 
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:185)
at 
org.apache.geronimo.kernel.config.Configuration.(Configuration.java:297)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
at 
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:359)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:163)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815)
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.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$55935236.loadConfiguration()
at 
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158)
at 
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at 
org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30){code}

Config.xml still contains:
{code:xml|title=config.xml}


4096
0
8443
ISO-8859-1
false
false
false
0.0.0.0
2048
text/html,text/xml,text/plain
off
-1
6
6
true
4096
100
40
10
100
802
null
9000
true
5

{code}

  was:
When removing a connector, it removes the connector from tomcat's server.xml, 
but not the GBean from config.xml, so when stopping and again start the server, 
the server fails to star

[jira] Updated: (GERONIMO-4860) WebManagerPortlet doesn't complete remove a connector - leads to inability to start server


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

Quintin Beukes updated GERONIMO-4860:
-

Description: 
When removing a connector, it removes the connector from tomcat's server.xml, 
but not the GBean from config.xml, so when stopping and again start the server, 
the server fails to start with: 
{code:title=geronimo.log}2009-09-10 10:45:28,076 ERROR [GBeanInstanceState] 
Error while starting; GBean is now in the FAILED state: 
abstractName="org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car"
org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans must be 
specified with a GBeanInfo 
configuration=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car 
gbeanName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car,j2eeType=GBean,name=testConnector1
at 
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:185)
at 
org.apache.geronimo.kernel.config.Configuration.(Configuration.java:297)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
at 
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:359)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:163)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815)
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.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$55935236.loadConfiguration()
at 
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158)
at 
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at 
org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30){code}

Config.xml still contains:
{code:xml}

4096
0
8443
ISO-8859-1
false
false
false
0.0.0.0
2048
text/html,text/xml,text/plain
off
-1
6
6
true
4096
100
40
10
100
802
null
9000
true
5

{code}

  was:
When removing a connector, it removes the connector from tomcat's server.xml, 
but not the GBean from config.xml, so when stopping and again start the server, 
the server fails to start with: 
{{2009-09-1

[jira] Updated: (GERONIMO-4860) WebManagerPortlet doesn't complete remove a connector - leads to inability to start server


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

Quintin Beukes updated GERONIMO-4860:
-

Description: 
When removing a connector, it removes the connector from tomcat's server.xml, 
but not the GBean from config.xml, so when stopping and again start the server, 
the server fails to start with: 
{{2009-09-10 10:45:28,076 ERROR [GBeanInstanceState] Error while starting; 
GBean is now in the FAILED state: 
abstractName="org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car"
org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans must be 
specified with a GBeanInfo 
configuration=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car 
gbeanName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car,j2eeType=GBean,name=testConnector1
at 
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:185)
at 
org.apache.geronimo.kernel.config.Configuration.(Configuration.java:297)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
at 
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:359)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:163)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815)
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.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$55935236.loadConfiguration()
at 
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158)
at 
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)}}

Config.xml still contains:
{{

4096
0
8443
ISO-8859-1
false
false
false
0.0.0.0
2048
text/html,text/xml,text/plain
off
-1
6
6
true
4096
100
40
10
100
802
null
9000
true
5

}}

  was:
When removing a connector, it removes the connector from tomcat's server.xml, 
but not the GBean from config.xml, so when stopping and again start the server, 
the server fails to start with: 
2009-09-10 10:45:28,076 ERROR [GBeanInstanceState] Error while sta

[jira] Created: (GERONIMO-4860) WebManagerPortlet doesn't complete remove a connector - leads to inability to start server

WebManagerPortlet doesn't complete remove a connector - leads to inability to 
start server
--

 Key: GERONIMO-4860
 URL: https://issues.apache.org/jira/browse/GERONIMO-4860
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: connector, console
Affects Versions: 2.2
Reporter: Quintin Beukes
 Fix For: 2.2


When removing a connector, it removes the connector from tomcat's server.xml, 
but not the GBean from config.xml, so when stopping and again start the server, 
the server fails to start with: 
2009-09-10 10:45:28,076 ERROR [GBeanInstanceState] Error while starting; GBean 
is now in the FAILED state: 
abstractName="org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car"
org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans must be 
specified with a GBeanInfo 
configuration=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car 
gbeanName=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car,j2eeType=GBean,name=testConnector1
at 
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:185)
at 
org.apache.geronimo.kernel.config.Configuration.(Configuration.java:297)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952)
at 
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96)
at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:910)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:524)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:359)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:163)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815)
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.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$55935236.loadConfiguration()
at 
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158)
at 
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)

Config.xml still contains:


4096
0
8443
ISO-8859-1
false
false
false
0.0.0.0
2048
text/html,text/xml,text/plain
off
-1
6
6
true
4096
100
40
10
100
802
null
9000

Re: [DISCUSS] Release Blueprint 1.0.0

2009-09-09 Thread Quintin Beukes

What is Blueprint. I had a look around on the site and can't find it there.

Q

On Wed, Sep 9, 2009 at 7:49 PM, Kevan Miller  wrote:
>
> On Sep 9, 2009, at 12:37 PM, David Jencks wrote:
>
> Without some major justification I'm seriously -1 on releasing from the
> sandbox.  I don't see any problem with moving this code to components and
> releasing it from there, whether or not it then moves somewhere else.
>
> Agreed that we should not release from sandbox. I'm a bit reluctant about a
> release, but nor do I see a big reason not to release and don't want to
> cause problems for Karaf. So, I'm good with a components release.
> --kevan



-- 
Quintin Beukes

[jira] Commented: (GERONIMO-4852) Fail to connect to a new created Tomcat BIO HTTPS Connector network listener

2009-09-09 Thread Quintin Beukes (JIRA)


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

Quintin Beukes commented on GERONIMO-4852:
--

Was there perhaps a restart in between where it worked and where it doesn't? 
See if you are able to connect to port 8443. 

This could be related to but: 
https://issues.apache.org/jira/browse/GERONIMO-4852

> Fail to connect to a new created Tomcat BIO HTTPS Connector network listener
> 
>
> Key: GERONIMO-4852
> URL: https://issues.apache.org/jira/browse/GERONIMO-4852
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.2
> Environment: winxp sp3, jdk 1.6
>Reporter: Shiny Cheng
> Fix For: 2.2
>
>
> When I created a new Tomcat BIO HTTPS Connector network listener, I set 
> keystoreFile as ../security/keystores/geronimo-default, port as 8444 (also 
> tried other ones not equal to 8443), algorithm as Default, keystorePass as 
> secret. 
> Following these settings, I successed once, i.e. I can smoothly connect to 
> the port. However, other times, I always failed to connect to the listener. 

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

[jira] Created: (GERONIMO-4858) Geronimo 2.2 doesn't ad

2009-09-09 Thread Quintin Beukes (JIRA)

Geronimo 2.2 doesn't ad
---

 Key: GERONIMO-4858
 URL: https://issues.apache.org/jira/browse/GERONIMO-4858
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: connector, console
Affects Versions: 2.2, 3.0
Reporter: Quintin Beukes
Priority: Critical
 Fix For: 2.2


OK. So I extract the 2009-09-08 nightly snapshot (tomcat binary), and deploy 
some repository JARs, a datasource and a security realm. Then I goto Web Server 
portlet and create a new Tomcat BIO connector. I enter a name, and for port I 
enter 80. This is a rough of the steps I took from a clean install.

So the bug is that when you add a connector, it immediately starts it on the 
correct port (as can be seen with netstat), but it saves to 
var/catalina/server.xml with port 8080. So once you restart the server you 
receive a port conflict if you have another 8080, and if you don't it would be 
like you never made the change, with your connector reverting to 8080.

Here is a snippet of what it saves after adding a port "801" BIO connector:


Q


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

[jira] Updated: (GERONIMO-4848) Application Client Login Retries

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

Quintin Beukes updated GERONIMO-4848:
-

Description:
When an application client is configured to authenticate with a JAAS realm and
a CallbackHandler, the login is performed before the application's main method
is called, thus outside the context of the client application itself.

This all works, except a failed login isn't retried and there is no way for the
application to even detect this (nor a cancel if such an option existed).

The attached patch is a modification of
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.

- It introduces a login retry facility. It does so by supplying an optional
extra "option", which can be specified in the gbean configuration, like so:
...

remote-openejb-realm

net.kunye.platform.security.auth.ApplicationClientLoginModule
KMSRealm
ejbd://localhost:4201
3

...

- If you omit this option, it will default to the current behaviour of "1" try.

- If you supply an invalid value for an option (any value that would raise a
NumberFormatException when calling "Integer.parseInt()"), it will default to
the current behaviour of "1" try.

- If you specify an integer great or equal to 0, it will perform the given
amount of tries. If no successful authentication occurred during these tries it
will fail with the FailedLoginException (as it does currently).

- If you specify 0 login tries, then it will keep trying until either a
successful authentication or the user cancelled. The cancel is detected by
setting either the NameCallback or PasswordCallback's value to null. This is
quite unintuitive and might make it more difficult to find bugs in your code
where the values are unintentionally null, so an alternative way might be
better.

Note: The "cancel" check works for all logins, including the first try.

- Further, if a "cancel" is detected, the callback handler is invoked with a
single TextOutputCallback which contains an INFORMATION type message "Login
cancelled by user.".

- If authentication failed, the callback handler is invoked with a single
TextOutputCallback which contains an ERROR type message "Login failed for user:
${USER}", where USER is the username of the last NameCallback.

The justification of implementing this in the LoginModule and not the
application client is to have more direct access to the CallbackHandler, so as
to send the "Login Failed" and "Login canceled" messages. Also the fact that
certain types of login modules might be used which don't support the "concept"
of a retry, like host based authentication modules. So doing retries in the
application client layer didn't seem logical. This way you can also extend the
class or build your own and ship it with your application, and so be able to
customize the retry behaviour, instead of relying on a fixed retry strategy in
the application client layer (which could only be changed by recompiling the
plugin).

Any suggestions/requests, just let me know and I'll implement them.

was:
When an application client is configured to authenticate with a JAAS realm and
a CallbackHandler, the login is performed before the application's main method
is called, thus outside the context of the client application itself.

This all works, except a failed login isn't retried and there is no way for the
application to even detect this (nor a cancel if such an option existed).

The attached patch is a modification of
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.

- It introduces a login retry facility. It does so by supplying an optional
extra "option", which can be specified in the gbean configuration, like so:
...

remote-openejb-realm

net.kunye.platform.security.auth.ApplicationClientLoginModule
KMSRealm
ejbd://localhost:4201
3

...

- If you omit this option, it will default to the current behaviour of "1" try.

Note: The "cancel" check works for all logins, including the first try.

- Further,

[jira] Updated: (GERONIMO-4848) Application Client Login Retries


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

Quintin Beukes updated GERONIMO-4848:
-

Comment: was deleted

(was: Patch for the new login module, as well as the complete class for those 
who wish to view it without having to first apply the patch.)

> Application Client Login Retries
> 
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: application client, security
>Affects Versions: 2.1.4
>    Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm 
> and a CallbackHandler, the login is performed before the application's main 
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for 
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of 
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional 
> extra "option", which can be specified in the gbean configuration, like so:
> ...
> 
>   remote-openejb-realm
>   
> net.kunye.platform.security.auth.ApplicationClientLoginModule
>   KMSRealm
>   ejbd://localhost:4201
>   3
> 
> ...
> - If you omit this option, it will default to the current behaviour of "1" 
> try.
> - If you specify an integer great or equal to 0, it will perform the given 
> amount of tries. If no successful authentication occurred during these tries 
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a 
> successful authentication or the user cancelled. The cancel is detected by 
> setting either the NameCallback or PasswordCallback's value to null. This is 
> quite unintuitive and might make it more difficult to find bugs in your code 
> where the values are unintentionally null, so an alternative way might be 
> better. 
> Note: The "cancel" check works for all logins, including the first try. 
> - Further, if a "cancel" is detected, the callback handler is invoked with a 
> single TextOutputCallback which contains an INFORMATION type message "Login 
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single 
> TextOutputCallback which contains an ERROR type message "Login failed for 
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the 
> application client is to have more direct access to the CallbackHandler, so 
> as to send the "Login Failed" and "Login canceled" messages. Also the fact 
> that certain types of login modules might be used which don't support the 
> "concept" of a retry, like host based authentication modules. So doing 
> retries in the application client layer didn't seem logical. This way you can 
> also extend the class or build your own and ship it with your application, 
> and so be able to customize the retry behaviour, instead of relying on a 
> fixed retry strategy in the application client layer (which could only be 
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Updated: (GERONIMO-4848) Application Client Login Retries


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

Quintin Beukes updated GERONIMO-4848:
-

Attachment: login-retries.patch
OpenejbRemoteLoginModule.java

Patch as described in the issue's description as well as the full class to read 
the code without having to patch an older version.

> Application Client Login Retries
> 
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm 
> and a CallbackHandler, the login is performed before the application's main 
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for 
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of 
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional 
> extra "option", which can be specified in the gbean configuration, like so:
> ...
> 
>   remote-openejb-realm
>   
> net.kunye.platform.security.auth.ApplicationClientLoginModule
>   KMSRealm
>   ejbd://localhost:4201
>   3
> 
> ...
> - If you omit this option, it will default to the current behaviour of "1" 
> try.
> - If you specify an integer great or equal to 0, it will perform the given 
> amount of tries. If no successful authentication occurred during these tries 
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a 
> successful authentication or the user cancelled. The cancel is detected by 
> setting either the NameCallback or PasswordCallback's value to null. This is 
> quite unintuitive and might make it more difficult to find bugs in your code 
> where the values are unintentionally null, so an alternative way might be 
> better. 
> Note: The "cancel" check works for all logins, including the first try. 
> - Further, if a "cancel" is detected, the callback handler is invoked with a 
> single TextOutputCallback which contains an INFORMATION type message "Login 
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single 
> TextOutputCallback which contains an ERROR type message "Login failed for 
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the 
> application client is to have more direct access to the CallbackHandler, so 
> as to send the "Login Failed" and "Login canceled" messages. Also the fact 
> that certain types of login modules might be used which don't support the 
> "concept" of a retry, like host based authentication modules. So doing 
> retries in the application client layer didn't seem logical. This way you can 
> also extend the class or build your own and ship it with your application, 
> and so be able to customize the retry behaviour, instead of relying on a 
> fixed retry strategy in the application client layer (which could only be 
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Issue Comment Edited: (GERONIMO-4848) Application Client Login Retries


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

Quintin Beukes edited comment on GERONIMO-4848 at 9/4/09 12:47 PM:
---

I named the option "FailedLoginTries". It was actually renamed from 
"FailedLoginRetries", but after I changed it's purpose, I changed to "Tries", 
but didn't realize that the name is deceiving.

I changed the option to "LoginAttempts", so the attached patch and class will 
use "LoginAttempts" instead.

  was (Author: quin...@last.za.net):
I named the option "FailedLoginTries". It was actually renamed from 
"FailedLoginRetries", but after I changed it's purpose, I changed to "Tries", 
but didn't realize that the name is deceiving.

A better name might be "LoginAttempts".
  
> Application Client Login Retries
> 
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm 
> and a CallbackHandler, the login is performed before the application's main 
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for 
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of 
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional 
> extra "option", which can be specified in the gbean configuration, like so:
> ...
> 
>   remote-openejb-realm
>   
> net.kunye.platform.security.auth.ApplicationClientLoginModule
>   KMSRealm
>   ejbd://localhost:4201
>   3
> 
> ...
> - If you omit this option, it will default to the current behaviour of "1" 
> try.
> - If you specify an integer great or equal to 0, it will perform the given 
> amount of tries. If no successful authentication occurred during these tries 
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a 
> successful authentication or the user cancelled. The cancel is detected by 
> setting either the NameCallback or PasswordCallback's value to null. This is 
> quite unintuitive and might make it more difficult to find bugs in your code 
> where the values are unintentionally null, so an alternative way might be 
> better. 
> Note: The "cancel" check works for all logins, including the first try. 
> - Further, if a "cancel" is detected, the callback handler is invoked with a 
> single TextOutputCallback which contains an INFORMATION type message "Login 
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single 
> TextOutputCallback which contains an ERROR type message "Login failed for 
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the 
> application client is to have more direct access to the CallbackHandler, so 
> as to send the "Login Failed" and "Login canceled" messages. Also the fact 
> that certain types of login modules might be used which don't support the 
> "concept" of a retry, like host based authentication modules. So doing 
> retries in the application client layer didn't seem logical. This way you can 
> also extend the class or build your own and ship it with your application, 
> and so be able to customize the retry behaviour, instead of relying on a 
> fixed retry strategy in the application client layer (which could only be 
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Updated: (GERONIMO-4848) Application Client Login Retries


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

Quintin Beukes updated GERONIMO-4848:
-

Attachment: (was: OpenejbRemoteLoginModule.java)

> Application Client Login Retries
> 
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: application client, security
>Affects Versions: 2.1.4
>    Reporter: Quintin Beukes
>Priority: Minor
>
> When an application client is configured to authenticate with a JAAS realm 
> and a CallbackHandler, the login is performed before the application's main 
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for 
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of 
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional 
> extra "option", which can be specified in the gbean configuration, like so:
> ...
> 
>   remote-openejb-realm
>   
> net.kunye.platform.security.auth.ApplicationClientLoginModule
>   KMSRealm
>   ejbd://localhost:4201
>   3
> 
> ...
> - If you omit this option, it will default to the current behaviour of "1" 
> try.
> - If you specify an integer great or equal to 0, it will perform the given 
> amount of tries. If no successful authentication occurred during these tries 
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a 
> successful authentication or the user cancelled. The cancel is detected by 
> setting either the NameCallback or PasswordCallback's value to null. This is 
> quite unintuitive and might make it more difficult to find bugs in your code 
> where the values are unintentionally null, so an alternative way might be 
> better. 
> Note: The "cancel" check works for all logins, including the first try. 
> - Further, if a "cancel" is detected, the callback handler is invoked with a 
> single TextOutputCallback which contains an INFORMATION type message "Login 
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single 
> TextOutputCallback which contains an ERROR type message "Login failed for 
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the 
> application client is to have more direct access to the CallbackHandler, so 
> as to send the "Login Failed" and "Login canceled" messages. Also the fact 
> that certain types of login modules might be used which don't support the 
> "concept" of a retry, like host based authentication modules. So doing 
> retries in the application client layer didn't seem logical. This way you can 
> also extend the class or build your own and ship it with your application, 
> and so be able to customize the retry behaviour, instead of relying on a 
> fixed retry strategy in the application client layer (which could only be 
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Updated: (GERONIMO-4848) Application Client Login Retries


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

Quintin Beukes updated GERONIMO-4848:
-

Attachment: (was: login-retries.patch)

> Application Client Login Retries
> 
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: application client, security
>Affects Versions: 2.1.4
>    Reporter: Quintin Beukes
>Priority: Minor
>
> When an application client is configured to authenticate with a JAAS realm 
> and a CallbackHandler, the login is performed before the application's main 
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for 
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of 
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional 
> extra "option", which can be specified in the gbean configuration, like so:
> ...
> 
>   remote-openejb-realm
>   
> net.kunye.platform.security.auth.ApplicationClientLoginModule
>   KMSRealm
>   ejbd://localhost:4201
>   3
> 
> ...
> - If you omit this option, it will default to the current behaviour of "1" 
> try.
> - If you specify an integer great or equal to 0, it will perform the given 
> amount of tries. If no successful authentication occurred during these tries 
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a 
> successful authentication or the user cancelled. The cancel is detected by 
> setting either the NameCallback or PasswordCallback's value to null. This is 
> quite unintuitive and might make it more difficult to find bugs in your code 
> where the values are unintentionally null, so an alternative way might be 
> better. 
> Note: The "cancel" check works for all logins, including the first try. 
> - Further, if a "cancel" is detected, the callback handler is invoked with a 
> single TextOutputCallback which contains an INFORMATION type message "Login 
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single 
> TextOutputCallback which contains an ERROR type message "Login failed for 
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the 
> application client is to have more direct access to the CallbackHandler, so 
> as to send the "Login Failed" and "Login canceled" messages. Also the fact 
> that certain types of login modules might be used which don't support the 
> "concept" of a retry, like host based authentication modules. So doing 
> retries in the application client layer didn't seem logical. This way you can 
> also extend the class or build your own and ship it with your application, 
> and so be able to customize the retry behaviour, instead of relying on a 
> fixed retry strategy in the application client layer (which could only be 
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Commented: (GERONIMO-4848) Application Client Login Retries


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

Quintin Beukes commented on GERONIMO-4848:
--

I named the option "FailedLoginTries". It was actually renamed from 
"FailedLoginRetries", but after I changed it's purpose, I changed to "Tries", 
but didn't realize that the name is deceiving.

A better name might be "LoginAttempts".

> Application Client Login Retries
> 
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: application client, security
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm 
> and a CallbackHandler, the login is performed before the application's main 
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for 
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of 
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional 
> extra "option", which can be specified in the gbean configuration, like so:
> ...
> 
>   remote-openejb-realm
>   
> net.kunye.platform.security.auth.ApplicationClientLoginModule
>   KMSRealm
>   ejbd://localhost:4201
>   3
> 
> ...
> - If you omit this option, it will default to the current behaviour of "1" 
> try.
> - If you specify an integer great or equal to 0, it will perform the given 
> amount of tries. If no successful authentication occurred during these tries 
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a 
> successful authentication or the user cancelled. The cancel is detected by 
> setting either the NameCallback or PasswordCallback's value to null. This is 
> quite unintuitive and might make it more difficult to find bugs in your code 
> where the values are unintentionally null, so an alternative way might be 
> better. 
> Note: The "cancel" check works for all logins, including the first try. 
> - Further, if a "cancel" is detected, the callback handler is invoked with a 
> single TextOutputCallback which contains an INFORMATION type message "Login 
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single 
> TextOutputCallback which contains an ERROR type message "Login failed for 
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the 
> application client is to have more direct access to the CallbackHandler, so 
> as to send the "Login Failed" and "Login canceled" messages. Also the fact 
> that certain types of login modules might be used which don't support the 
> "concept" of a retry, like host based authentication modules. So doing 
> retries in the application client layer didn't seem logical. This way you can 
> also extend the class or build your own and ship it with your application, 
> and so be able to customize the retry behaviour, instead of relying on a 
> fixed retry strategy in the application client layer (which could only be 
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Updated: (GERONIMO-4848) Application Client Login Retries


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

Quintin Beukes updated GERONIMO-4848:
-

Attachment: OpenejbRemoteLoginModule.java
login-retries.patch

Patch for the new login module, as well as the complete class for those who 
wish to view it without having to first apply the patch.

> Application Client Login Retries
> 
>
> Key: GERONIMO-4848
> URL: https://issues.apache.org/jira/browse/GERONIMO-4848
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: application client, security
>Affects Versions: 2.1.4
>    Reporter: Quintin Beukes
>Priority: Minor
> Attachments: login-retries.patch, OpenejbRemoteLoginModule.java
>
>
> When an application client is configured to authenticate with a JAAS realm 
> and a CallbackHandler, the login is performed before the application's main 
> method is called, thus outside the context of the client application itself.
> This all works, except a failed login isn't retried and there is no way for 
> the application to even detect this (nor a cancel if such an option existed).
> The attached patch is a modification of 
> org.apache.geronimo.openejb.OpenejbRemoteLoginModule.
> - It introduces a login retry facility. It does so by supplying an optional 
> extra "option", which can be specified in the gbean configuration, like so:
> ...
> 
>   remote-openejb-realm
>   
> net.kunye.platform.security.auth.ApplicationClientLoginModule
>   KMSRealm
>   ejbd://localhost:4201
>   3
> 
> ...
> - If you omit this option, it will default to the current behaviour of "1" 
> try.
> - If you specify an integer great or equal to 0, it will perform the given 
> amount of tries. If no successful authentication occurred during these tries 
> it will fail with the FailedLoginException (as it does currently).
> - If you specify 0 login tries, then it will keep trying until either a 
> successful authentication or the user cancelled. The cancel is detected by 
> setting either the NameCallback or PasswordCallback's value to null. This is 
> quite unintuitive and might make it more difficult to find bugs in your code 
> where the values are unintentionally null, so an alternative way might be 
> better. 
> Note: The "cancel" check works for all logins, including the first try. 
> - Further, if a "cancel" is detected, the callback handler is invoked with a 
> single TextOutputCallback which contains an INFORMATION type message "Login 
> cancelled by user.".
> - If authentication failed, the callback handler is invoked with a single 
> TextOutputCallback which contains an ERROR type message "Login failed for 
> user: ${USER}", where USER is the username of the last NameCallback.
> The justification of implementing this in the LoginModule and not the 
> application client is to have more direct access to the CallbackHandler, so 
> as to send the "Login Failed" and "Login canceled" messages. Also the fact 
> that certain types of login modules might be used which don't support the 
> "concept" of a retry, like host based authentication modules. So doing 
> retries in the application client layer didn't seem logical. This way you can 
> also extend the class or build your own and ship it with your application, 
> and so be able to customize the retry behaviour, instead of relying on a 
> fixed retry strategy in the application client layer (which could only be 
> changed by recompiling the plugin).
> Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Created: (GERONIMO-4848) Application Client Login Retries

Application Client Login Retries


 Key: GERONIMO-4848
 URL: https://issues.apache.org/jira/browse/GERONIMO-4848
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: application client, security
Affects Versions: 2.1.4
Reporter: Quintin Beukes
Priority: Minor


When an application client is configured to authenticate with a JAAS realm and 
a CallbackHandler, the login is performed before the application's main method 
is called, thus outside the context of the client application itself.

This all works, except a failed login isn't retried and there is no way for the 
application to even detect this (nor a cancel if such an option existed).

The attached patch is a modification of 
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.

- It introduces a login retry facility. It does so by supplying an optional 
extra "option", which can be specified in the gbean configuration, like so:
...

  remote-openejb-realm
  
net.kunye.platform.security.auth.ApplicationClientLoginModule
  KMSRealm
  ejbd://localhost:4201
  3

...

- If you omit this option, it will default to the current behaviour of "1" try.

- If you specify an integer great or equal to 0, it will perform the given 
amount of tries. If no successful authentication occurred during these tries it 
will fail with the FailedLoginException (as it does currently).

- If you specify 0 login tries, then it will keep trying until either a 
successful authentication or the user cancelled. The cancel is detected by 
setting either the NameCallback or PasswordCallback's value to null. This is 
quite unintuitive and might make it more difficult to find bugs in your code 
where the values are unintentionally null, so an alternative way might be 
better. 

Note: The "cancel" check works for all logins, including the first try. 

- Further, if a "cancel" is detected, the callback handler is invoked with a 
single TextOutputCallback which contains an INFORMATION type message "Login 
cancelled by user.".

- If authentication failed, the callback handler is invoked with a single 
TextOutputCallback which contains an ERROR type message "Login failed for user: 
${USER}", where USER is the username of the last NameCallback.

The justification of implementing this in the LoginModule and not the 
application client is to have more direct access to the CallbackHandler, so as 
to send the "Login Failed" and "Login canceled" messages. Also the fact that 
certain types of login modules might be used which don't support the "concept" 
of a retry, like host based authentication modules. So doing retries in the 
application client layer didn't seem logical. This way you can also extend the 
class or build your own and ship it with your application, and so be able to 
customize the retry behaviour, instead of relying on a fixed retry strategy in 
the application client layer (which could only be changed by recompiling the 
plugin).

Any suggestions/requests, just let me know and I'll implement them.

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

[jira] Updated: (GERONIMO-4847) HTTP 500 error from exception when adding a repository resource which already exists


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

Quintin Beukes updated GERONIMO-4847:
-

Description: 
Adding a repository resource which already exists gives an HTTP 500 (from 
exception) error. It should instead prompt to override or show a friendlier 
message.

An example stack trace is:
java.lang.IllegalArgumentException: Destination 
/opt/kms/server/geronimo-2.1.4/repository/kms/GeronimoLoginModule/1.0/GeronimoLoginModule-1.0.jar
 already exists!

org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:213)

org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:189)

org.apache.geronimo.console.repository.RepositoryViewPortlet.processAction(RepositoryViewPortlet.java:169)
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145)
javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)

org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)

org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85)

org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219)

org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121)

org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167)
javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)

org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125)


  was:
Adding a resource which already exists gives an HTTP 500 (from exception) 
error. It should instead prompt to override or show a friendlier message.

An example stack trace is:
java.lang.IllegalArgumentException: Destination 
/opt/kms/server/geronimo-2.1.4/repository/kms/GeronimoLoginModule/1.0/GeronimoLoginModule-1.0.jar
 already exists!

org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:213)

org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:189)

org.apache.geronimo.console.repository.RepositoryViewPortlet.processAction(RepositoryViewPortlet.java:169)
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145)
javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)

org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)

org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85)

org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219)

org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121)

org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:167)
javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)

org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125)


Summary: HTTP 500 error from exception when adding a repository 
resource which already exists  (was: HTTP 500 error from exception when adding 
a resource which already exists)

> HTTP 500 error from exception when adding a repository resource which already 
> exists
> 
>
> Key: GERONIMO-4847
> URL: https://issues.apache.org/jira/browse/GERONIMO-4847
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1.4
>Reporter: Quintin Beukes
>
> Adding a repository resource which already exists gives an HTTP 500 (from 
> exception) error. It should instead prompt to override or show a friendlier 
> message.
> An example stack trace is:
> java.lang.IllegalArgumentException: Destination 
> /opt/kms/server/geronimo-2.1.4/repository/kms/GeronimoLoginModule/1.0/GeronimoLoginModule-1.0.jar
>  already exists!
>   
> org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:213)
>   
> org.apache.geronimo.kernel.repository.AbstractRepository.copyToRepository(AbstractRepository.java:189)
>   
&

[jira] Created: (GERONIMO-4847) HTTP 500 error from exception when adding a resource which already exists