date:20070420

Re: tld version issue

2007-04-20 Thread Tim McConnell

Hi Don, I've found the problem causing your error and I've opened GERONIMO-3109 
to address the problem. Please let me know if my fix is working for you and 
whether you encounter any more problems.


David Jencks, could I ask you to review and commit the patch I've attached to 
GERONIMO-3019 to fix Don's problem ?? Also, I have a second patch for 
GERONIMO-3081 that I'd like to get reviewed and committed when you get a chance.


Thanks,
Tim McConnell


Don Hill wrote:

Heres the error and stack

struts-nested.tld:2323:1: error: cvc-complex-type.2.4c: Expected element 
'[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' before the end of the 
content in element [EMAIL PROTECTED]://java.sun.com/xml/ns/javaee


Descriptor:
http://java.sun.com/xml/ns/javaee 
  
http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd"; 
version="2.1" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; 
xmlns="http://java.sun.com/xml/ns/javaee";>

  1.2
  nested
  http://struts.apache.org/tags-nested
  
nest
org.apache.struts.taglib.nested.NestedPropertyTag 


JSP

  property
  false
  true

   ...


 at 
org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD(XmlBeansUtil.java:218)
at 
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.convertToTaglibSchema(JspModuleBuilderExtension.java:656)
at 
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java 
:434)
at 
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getListenerClasses(JspModuleBuilderExtension.java:421)
at 
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder 
(JspModuleBuilderExtension.java:181)
at 
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:150)
at 
org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension$$FastClassByCGLIB$$1f60ab3b.invoke 
()

at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)




On 4/18/07, *Don Hill* < [EMAIL PROTECTED] > 
wrote:


here you go struts-nested.tld, do ask me why they are using this
still ;)



On 4/18/07, *David Jencks* < [EMAIL PROTECTED]
> wrote:

I think we are trying to upgrade the tlds to the latest schema
and validate that.  Can you share the tld causing problems or at
least the stack trace indicating the problem?

thanks
david jencks

On Apr 18, 2007, at 8:29 AM, Don Hill wrote:


Hi,

build from trunk

I am trying to test a WAR that is using older taglib's, they
are version 1.2. The DOCTYPE has the DTD specified but it
seems this DTD is being ignored and the deployment tool is
trying to validate against the uri
http://java.sun.com/xml/ns/javaee, this is the uri specified
in the web.xml/web-app .


Is this a feature or an issue, I am not up to speed on the JSP
spec so maybe someone could shine some light here.

Thanks!!!

[jira] Updated: (GERONIMO-3109) struts-nested.tld conversion error

2007-04-20 Thread Tim McConnell (JIRA)


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

Tim McConnell updated GERONIMO-3109:


Attachment: GERONIMO-3109.patch

When converting the older versions of taglib files I missed the singular case 
where a tag was not required in the 1.1 or 1.2 DTD but is now required in the 
2.1 XSD schema (i.e., ). This patch fixes that problem.

> struts-nested.tld conversion error
> --
>
> Key: GERONIMO-3109
> URL: https://issues.apache.org/jira/browse/GERONIMO-3109
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>Reporter: Tim McConnell
> Assigned To: Tim McConnell
> Attachments: GERONIMO-3109.patch
>
>


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

[RESULT][VOTE] Release XBean 3.0

2007-04-20 Thread Guillaume Nodet


The vote has passed with 6 +1s and no other votes.
I will move the release to their final location asap.

On 4/17/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:


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

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

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

--
Cheers,
Guillaume Nodet

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





--
Cheers,
Guillaume Nodet

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

[jira] Resolved: (GERONIMO-2730) JAX-RPC EJB Web Services support appears to be broken

2007-04-20 Thread Jarek Gawor (JIRA)


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

Jarek Gawor resolved GERONIMO-2730.
---

Resolution: Fixed

The remaining OpenEJB issues were resolved so JAX-RPC EJB web services should 
be working now in Geronimo.


> JAX-RPC EJB Web Services support appears to be broken
> -
>
> Key: GERONIMO-2730
> URL: https://issues.apache.org/jira/browse/GERONIMO-2730
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M2
>Reporter: Jarek Gawor
> Assigned To: Jarek Gawor
> Attachments: jaxrpc-ejb-tests.patch
>
>
> The JAX-RPC-based EJB web services support appears to be broken. I'm 
> attaching test code that demonstrates the problems. Please note that the test 
> WS is identical as in the POJO tests (see 
> https://issues.apache.org/jira/browse/GERONIMO-2729) where it works fine.
> Here are the problems discovered:
> 1) By default, jar deployment with WS EJB will fail with:
> Deployer operation failed: Unable to resolve reference "WebServiceContainer" 
> in
> gbean 
> JEE5/JAXRPCEJB/1.1/car?EJBModule=JEE5/JAXRPCEJB/1.1/car,J2EEApplication=nu
> ll,StatelessSessionBean=Greeter,j2eeType=WSLink,name=Greeter to a gbean 
> matching
>  the pattern [?name=JettyWebContainer#]due to: No matches for 
> referencePatterns:
>  [?name=JettyWebContainer#]
> This can be fixed by adding an explicit dependency on the given container in 
> the open-ejb.xml file (see the open-ejb.xml in the attached patch). I think 
> such dependency should be automatically added by the deployer.
> 2) ?wsdl on the service fails with the following error:
> HttpException(500,Could not fetch wsdl!,java.lang.IllegalStateException: 
> request
>  must contain a  wsdl or WSDL parameter: {wsdl=[Ljava.lang.String;@11054a5})
> at 
> org.apache.geronimo.jetty6.JettyEJBWebServiceContext.handle(JettyEJBW
> ebServiceContext.java:147)
> 3) Invocation on the service fails with:
> 
> {http://xml.apache.org/axis/}stackTrace:java.lang.IndexOutOfBoundsExcept
> ion: Index: 0, Size: 0
> at java.util.ArrayList.RangeCheck(ArrayList.java:546)
> at java.util.ArrayList.get(ArrayList.java:321)
> at 
> org.apache.axis.description.JavaServiceDesc.getOperationsByQName(Java
> ServiceDesc.java:520)
> at 
> org.apache.axis.description.JavaServiceDesc.getOperationByElementQNam
> e(JavaServiceDesc.java:465)
> at 
> org.apache.geronimo.axis.server.ReadOnlyServiceDesc.getOperationByEle
> mentQName(ReadOnlyServiceDesc.java:151)
> at 
> org.apache.axis.providers.java.RPCProvider.getOperationDesc(RPCProvid
> er.java:296)
> at 
> org.apache.openejb.server.axis.EJBContainerProvider.processMessage(EJ
> BContainerProvider.java:62)
> These errors were discovered when using trunk with jetty6. 
> Since openejb will be updated in trunk shortly, I think these errors can be 
> ignored for now. However, I do not know if the same problems exist in 
> Geronimo 1.2 for example.

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

[jira] Created: (GERONIMO-3109) struts-nested.tld conversion error

2007-04-20 Thread Tim McConnell (JIRA)

struts-nested.tld conversion error
--

 Key: GERONIMO-3109
 URL: https://issues.apache.org/jira/browse/GERONIMO-3109
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public (Regular issues)
Reporter: Tim McConnell
 Assigned To: Tim McConnell




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

Re: [VOTE] Release XBean 3.0

2007-04-20 Thread Dain Sundstrom


+1

-dain

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


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

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


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

--
Cheers,
Guillaume Nodet

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

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

2007-04-20 Thread Dain Sundstrom


+1

-dain

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

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


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

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

This vote will conclude Saturday April 21 at 1300 Eastern

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

2007-04-20 Thread Dain Sundstrom


+1

-dain

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

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


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

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

This vote will conclude Saturday April 21 at 1300 Eastern

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

2007-04-20 Thread Dain Sundstrom


+1

-dain

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

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


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

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

This vote will conclude Saturday April 21 at 1300 Eastern

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

2007-04-20 Thread Dain Sundstrom


+1

-dain

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

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


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

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

This vote will conclude Saturday April 21 at 1300 Eastern

Re: AppClient security call back handlers essentially broken in 2.0

2007-04-20 Thread David Jencks

I'm pretty sure the additional issue is due to some ridiculous  
restrictions on which classloader certain porting classes need to be  
in for the tck.  The support in 1.2 for certain callback handlers  
without no-arg constructors is another attempt to work around  
weirdness in the tck.  We've found another way to deal with these  
issues with the javaee tck.  In other words I don't think  
anything is broken, and lets discuss this on the tck list.


thanks
david jencks

On Apr 20, 2007, at 6:54 AM, Rick McGuire wrote:

There appears to be one more issue with this.  I created a callback  
handler with a no-arg constructor so I could examine the behavior  
of what's going on, and I've discovered that there appears to be an  
issue with the classloader used to resolve the callback handler.   
My callback handler object is getting NoClassDefFound errors trying  
to access the  
org.apache.geronimo.security.realm.providers.CertificateChainCallback  
class.  It's not clear to me why this is a problem, since it  
appears the client config has a dependency on the geronimo-security  
module.


Rick

Rick McGuire wrote:
I've run into a serious problem with app client security callback  
handlers in Geronimo 2.0.  These appear to be completely broken,  
and I'm not sure I understand how to fix this.  Here's the scenario:


In 1.2, a security callback handler class can be specified in the  
plan.  In the main() method of the AppClientContainer, this was  
handled thusly:


   if (callbackHandlerClass != null) {
   //look for a constructor taking the args
   CallbackHandler callbackHandler;
   try {
   Constructor cArgs =  
callbackHandlerClass.getConstructor(new Class[] {String[].class});
   callbackHandler = (CallbackHandler)  
cArgs.newInstance(new Object[] {args});

   } catch (NoSuchMethodException e) {
   callbackHandler = (CallbackHandler)  
callbackHandlerClass.newInstance();

   }
   loginContext = new LoginContext(realmName,  
callbackHandler);

   try {
   loginContext.login();
   } catch (LoginException e) {
   loginContext = null;
   throw e;
   }
   clientSubject = loginContext.getSubject();
   }


The appclient container looked for a constructor on the target  
callback handler that took an array of Strings as an argument, and  
constructed that callback handler using the string arguments  
passed to the AppClientContainer main() method.  The callback  
handler would scan the application args looking for options that  
applied to its authentication technique, and it was passed to the  
loginContext in an initialized state, ready to provide addtional  
information to the login process.
In 2.0, this has changed drastically, breaking any call back  
handlers written for 1.2, and I don't even see an obvious method  
of fixing this.  Here's the new code for managing the callback  
handler:


   if (callbackHandlerClass != null) {
   callbackHandler = (CallbackHandler)  
holder.newInstance(callbackHandlerClass, classLoader,  
componentContext);
   loginContext = new LoginContext(realmName,  
callbackHandler);

   try {
   loginContext.login();
   } catch (LoginException e) {
   loginContext = null;
   throw e;
   }
   clientSubject = loginContext.getSubject();
   }

Same relative point in the AppClientContainer startup, but with  
two key differences:


  1. The holder.newInstance() call appears to be looking for a
 no-argument constructor on the callbackHandlerClass (which  
likely

 fails with the 1.2 classes because they are expecting to have
 their void CallbackHandler(String []) constructor called).
  2. The new callback handler instance is no longer being given  
access

 to the appclient args to initialize.  There appears to be some
 injection processing going on in the holder.newInstance() call,
 but it's not clear how to specify what information get injected,
 or even if the information from the appclient args is available.

So, how is this supposed to work, and if this is currently working  
correctly in 2.0, what is the process for converting a handler  
written for 1.2 into an equivalent for 2.0?


Rick

[jira] Commented: (GERONIMO-3108) Deploy fails when a WAR is deployed having a CSS file with special character

2007-04-20 Thread Jay D. McHugh (JIRA)


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

Jay D. McHugh commented on GERONIMO-3108:
-

Could you attach a test war file?

Also, what version of Java are you using?

> Deploy fails when a WAR is deployed having a CSS file with special character
> 
>
> Key: GERONIMO-3108
> URL: https://issues.apache.org/jira/browse/GERONIMO-3108
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.1.1
> Environment: Windows XP
>Reporter: Rajiv M
>Priority: Minor
>
> A WAR with a CSS file named with special characters fails to deploy  with the 
> below errors: 
> 15:06:12,580 ERROR [Deployer] Deployment failed: plan=null, 
> module=C:\AGDIR\var\temp\CssTest.war 
> org.apache.geronimo.common.DeploymentException: Could not construct URI for 
> location of war entry 
> at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.installModule(AbstractWebModuleBuilder.java:253)
>  
> at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClassByCGLIB$$459e0cc.invoke()
>  
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) 
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>  
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
>  
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>  
>  
> Caused by: 
> java.net.URISyntaxException: Illegal character in path at index 8: 
> test_ie7[1].css 
> at java.net.URI$Parser.fail(URI.java:2821) 
> at java.net.URI$Parser.checkChars(URI.java:2994) 
> at java.net.URI$Parser.parseHierarchical(URI.java:3078) 
> at java.net.URI$Parser.parse(URI.java:3036) 
> at java.net.URI.(URI.java:819) 
> at 
> org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.installModule 
> URI uri = new URI("http://localhost:80/test_ie7[1].css";) will cause the 
> exception to be thrown in a simple Java program. 
> Sun documentation (http://java.sun.com/j2se/1.5.0/docs/api/java/net/URI.html) 
> however mentions that [ and ] are legal URI characters. 
> Why the exception then?

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

[jira] Created: (GERONIMO-3108) Deploy fails when a WAR is deployed having a CSS file with special character

2007-04-20 Thread Rajiv M (JIRA)

Deploy fails when a WAR is deployed having a CSS file with special character


 Key: GERONIMO-3108
 URL: https://issues.apache.org/jira/browse/GERONIMO-3108
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 1.1.1
 Environment: Windows XP
Reporter: Rajiv M
Priority: Minor


A WAR with a CSS file named with special characters fails to deploy  with the 
below errors: 

15:06:12,580 ERROR [Deployer] Deployment failed: plan=null, 
module=C:\AGDIR\var\temp\CssTest.war 
org.apache.geronimo.common.DeploymentException: Could not construct URI for 
location of war entry 
at 
org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.installModule(AbstractWebModuleBuilder.java:253)
 
at 
org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClassByCGLIB$$459e0cc.invoke()
 
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) 
at 
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
 
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
 
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) 
 
Caused by: 
java.net.URISyntaxException: Illegal character in path at index 8: 
test_ie7[1].css 
at java.net.URI$Parser.fail(URI.java:2821) 
at java.net.URI$Parser.checkChars(URI.java:2994) 
at java.net.URI$Parser.parseHierarchical(URI.java:3078) 
at java.net.URI$Parser.parse(URI.java:3036) 
at java.net.URI.(URI.java:819) 
at 
org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.installModule 

URI uri = new URI("http://localhost:80/test_ie7[1].css";) will cause the 
exception to be thrown in a simple Java program. 

Sun documentation (http://java.sun.com/j2se/1.5.0/docs/api/java/net/URI.html) 
however mentions that [ and ] are legal URI characters. 

Why the exception then?


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

Re: Running multiple instances of geronimo

2007-04-20 Thread Anita Kulshreshtha


--- Ted Kirby <[EMAIL PROTECTED]> wrote:

> I like the notion of a pristine var to allow for easy instance
> creation.  When you say "by default", are you suggesting that we ship
> AG this way?  If this is done, then we must have geronimo and
> geronimo/var directories in the shipped image.  I see those are
> small.
   Initially yes, have a var and a geronimo/var (53K).
   Later we could have some code to do the copying. So given a server
name this code will create name/var (53K). This code could be part of 
J2EEDomain managedobject:
addServer(String serverName);
removeServer(String ServerName);
   We could make J2EEserver statemanageable, i.e. provide doStart() and
doStop() to start the instances. Some more thought is needed on how to
tie all this together...

>  Its the var/activemq/journals that are large (40MB), but they get
> created after the instance is started.
  yup, this will created when the instance is started.

Thanks
Anita


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

Re: AppClient security call back handlers essentially broken in 2.0

2007-04-20 Thread Rick McGuire

There appears to be one more issue with this.  I created a callback 
handler with a no-arg constructor so I could examine the behavior of 
what's going on, and I've discovered that there appears to be an issue 
with the classloader used to resolve the callback handler.  My callback 
handler object is getting NoClassDefFound errors trying to access the 
org.apache.geronimo.security.realm.providers.CertificateChainCallback 
class.  It's not clear to me why this is a problem, since it appears the 
client config has a dependency on the geronimo-security module.


Rick

Rick McGuire wrote:
I've run into a serious problem with app client security callback 
handlers in Geronimo 2.0.  These appear to be completely broken, and 
I'm not sure I understand how to fix this.  Here's the scenario:


In 1.2, a security callback handler class can be specified in the 
plan.  In the main() method of the AppClientContainer, this was 
handled thusly:


   if (callbackHandlerClass != null) {
   //look for a constructor taking the args
   CallbackHandler callbackHandler;
   try {
   Constructor cArgs = 
callbackHandlerClass.getConstructor(new Class[] {String[].class});
   callbackHandler = (CallbackHandler) 
cArgs.newInstance(new Object[] {args});

   } catch (NoSuchMethodException e) {
   callbackHandler = (CallbackHandler) 
callbackHandlerClass.newInstance();

   }
   loginContext = new LoginContext(realmName, 
callbackHandler);

   try {
   loginContext.login();
   } catch (LoginException e) {
   loginContext = null;
   throw e;
   }
   clientSubject = loginContext.getSubject();
   }


The appclient container looked for a constructor on the target 
callback handler that took an array of Strings as an argument, and 
constructed that callback handler using the string arguments passed to 
the AppClientContainer main() method.  The callback handler would scan 
the application args looking for options that applied to its 
authentication technique, and it was passed to the loginContext in an 
initialized state, ready to provide addtional information to the login 
process.
In 2.0, this has changed drastically, breaking any call back handlers 
written for 1.2, and I don't even see an obvious method of fixing 
this.  Here's the new code for managing the callback handler:


   if (callbackHandlerClass != null) {
   callbackHandler = (CallbackHandler) 
holder.newInstance(callbackHandlerClass, classLoader, componentContext);
   loginContext = new LoginContext(realmName, 
callbackHandler);

   try {
   loginContext.login();
   } catch (LoginException e) {
   loginContext = null;
   throw e;
   }
   clientSubject = loginContext.getSubject();
   }

Same relative point in the AppClientContainer startup, but with two 
key differences:


  1. The holder.newInstance() call appears to be looking for a
 no-argument constructor on the callbackHandlerClass (which likely
 fails with the 1.2 classes because they are expecting to have
 their void CallbackHandler(String []) constructor called).
  2. The new callback handler instance is no longer being given access
 to the appclient args to initialize.  There appears to be some
 injection processing going on in the holder.newInstance() call,
 but it's not clear how to specify what information get injected,
 or even if the information from the appclient args is available.

So, how is this supposed to work, and if this is currently working 
correctly in 2.0, what is the process for converting a handler written 
for 1.2 into an equivalent for 2.0?


Rick

Re: Running multiple instances of geronimo

2007-04-20 Thread Ted Kirby

Anita, keep up the good work! :)
I appreciate your efforts and documentation.
Please feel free to document the evolving steps and issues in the wiki
here: 
http://cwiki.apache.org/GMOxDOC20/multiple-repositories-and-server-instances.html

Ted Kirby

On 4/20/07, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote:

   Now the server instances can be run as follows:
1. create a directory in GERONIMO_HOME called say 'instance1'
2. copy 'var' directory to instance1.
3. edit instance1\var\config\config-substitutions.properties. Change
portOffset to 10, 20, .. (or anything else).
3. set GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=instance1
4. bin\startup
5.  To shutdown use bin\shutdown for the instance using 1099, and
bin\shutdown --port= for others. The console can also be
used.
6. To deploy from command line use:
  bin\deploy . for instance at 1099
  bin\deploy -port  deploy . for
others
  It would be nice if shutdown and deploy used same command syntax.
For the sake of uniformity, I would like to treat the server with
name geronimo', i.e.
gernimo:...j2eeType=J2EEServer,name=geronimo
  as an instance. In other words it will be run from geronimo/var (not
var). This will make a pristine copy of 'var' available all the time
for creating new instances. This can be easily done by setting the
property org.apache.geronimo.server.name=geronimo by default.

I like the notion of a pristine var to allow for easy instance
creation.  When you say "by default", are you suggesting that we ship
AG this way?  If this is done, then we must have geronimo and
geronimo/var directories in the shipped image.  I see those are small.
Its the var/activemq/journals that are large (40MB), but they get
created after the instance is started.

   Any other ideas are welcome..

Thanks
Anita

--- Anita Kulshreshtha <[EMAIL PROTECTED]> wrote:

> Hi All,
>  We need to make some additional [1] changes to the server to run
> multiple instances of geronimo:
> 1. By default i.e. bin\startup will start the server with a name (i1
> or
> something).
> 2.A pristine copy of var and deploy (empty directory) will be
> maintained at G_HOME, which could be used to start new instances. The
> G_HOME/deploy is not necessary in this case. The server directory
> will
> look like this:
>
> GERONIMO_HOME -
>   |- ...
>   | deploy - ??
>   |- var
>
>   |- instance1   -  var
>|-  deploy
>
>   |- instance2  -   var
>|-  deploy
>
>   |- ..
>
>
> [1] http://issues.apache.org/jira/browse/GERONIMO-3011
>
>
>
>
>

> The fish are biting.
> Get more visitors on your site using Yahoo! Search Marketing.
> http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
>

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

AppClient security call back handlers essentially broken in 2.0

2007-04-20 Thread Rick McGuire

I've run into a serious problem with app client security callback 
handlers in Geronimo 2.0.  These appear to be completely broken, and I'm 
not sure I understand how to fix this.  Here's the scenario:


In 1.2, a security callback handler class can be specified in the plan.  
In the main() method of the AppClientContainer, this was handled thusly:


   if (callbackHandlerClass != null) {
   //look for a constructor taking the args
   CallbackHandler callbackHandler;
   try {
   Constructor cArgs = 
callbackHandlerClass.getConstructor(new Class[] {String[].class});
   callbackHandler = (CallbackHandler) 
cArgs.newInstance(new Object[] {args});

   } catch (NoSuchMethodException e) {
   callbackHandler = (CallbackHandler) 
callbackHandlerClass.newInstance();

   }
   loginContext = new LoginContext(realmName, callbackHandler);
   try {
   loginContext.login();
   } catch (LoginException e) {
   loginContext = null;
   throw e;
   }
   clientSubject = loginContext.getSubject();
   }


The appclient container looked for a constructor on the target callback 
handler that took an array of Strings as an argument, and constructed 
that callback handler using the string arguments passed to the 
AppClientContainer main() method.  The callback handler would scan the 
application args looking for options that applied to its authentication 
technique, and it was passed to the loginContext in an initialized 
state, ready to provide addtional information to the login process. 

In 2.0, this has changed drastically, breaking any call back handlers 
written for 1.2, and I don't even see an obvious method of fixing this.  
Here's the new code for managing the callback handler:


   if (callbackHandlerClass != null) {
   callbackHandler = (CallbackHandler) 
holder.newInstance(callbackHandlerClass, classLoader, componentContext);

   loginContext = new LoginContext(realmName, callbackHandler);
   try {
   loginContext.login();
   } catch (LoginException e) {
   loginContext = null;
   throw e;
   }
   clientSubject = loginContext.getSubject();
   }

Same relative point in the AppClientContainer startup, but with two key 
differences:


  1. The holder.newInstance() call appears to be looking for a
 no-argument constructor on the callbackHandlerClass (which likely
 fails with the 1.2 classes because they are expecting to have
 their void CallbackHandler(String []) constructor called).
  2. The new callback handler instance is no longer being given access
 to the appclient args to initialize.  There appears to be some
 injection processing going on in the holder.newInstance() call,
 but it's not clear how to specify what information get injected,
 or even if the information from the appclient args is available.

So, how is this supposed to work, and if this is currently working 
correctly in 2.0, what is the process for converting a handler written 
for 1.2 into an equivalent for 2.0?


Rick

Re: Running multiple instances of geronimo

2007-04-20 Thread Anita Kulshreshtha

   Now the server instances can be run as follows:
1. create a directory in GERONIMO_HOME called say 'instance1'
2. copy 'var' directory to instance1.
3. edit instance1\var\config\config-substitutions.properties. Change
portOffset to 10, 20, .. (or anything else).
3. set GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=instance1
4. bin\startup
5.  To shutdown use bin\shutdown for the instance using 1099, and
bin\shutdown --port= for others. The console can also be
used.
6. To deploy from command line use:
  bin\deploy . for instance at 1099
  bin\deploy -port  deploy . for
others
  It would be nice if shutdown and deploy used same command syntax.
For the sake of uniformity, I would like to treat the server with
name geronimo', i.e.
gernimo:...j2eeType=J2EEServer,name=geronimo
  as an instance. In other words it will be run from geronimo/var (not
var). This will make a pristine copy of 'var' available all the time
for creating new instances. This can be easily done by setting the
property org.apache.geronimo.server.name=geronimo by default.
   Any other ideas are welcome..

Thanks
Anita

--- Anita Kulshreshtha <[EMAIL PROTECTED]> wrote:

> Hi All,
>  We need to make some additional [1] changes to the server to run
> multiple instances of geronimo:
> 1. By default i.e. bin\startup will start the server with a name (i1
> or
> something).
> 2.A pristine copy of var and deploy (empty directory) will be
> maintained at G_HOME, which could be used to start new instances. The
> G_HOME/deploy is not necessary in this case. The server directory
> will
> look like this:
> 
> GERONIMO_HOME - 
>   |- ...
>   | deploy - ??
>   |- var
> 
>   |- instance1   -  var
>|-  deploy
> 
>   |- instance2  -   var
>|-  deploy
> 
>   |- .. 
> 
>
> [1] http://issues.apache.org/jira/browse/GERONIMO-3011
> 
> 
> 
>  
>

> The fish are biting. 
> Get more visitors on your site using Yahoo! Search Marketing.
> http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
> 

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

Re: [jira] Commented: (GERONIMO-3106) When you are in the Create Database Pool wizard the jar driver list could show only jars containing Driver implementations

2007-04-20 Thread Daniel Alheiros

Hi David

I¹m OK with the filter idea you just explained, I still think it¹s more
useful than the jar list itself, but at least you will have all you need.

About the class it¹s more related to how the classloaders will interact and
how my application will be able to determine wich Driver version should use
as you have more than one available.

Imagine you create 2 datasources, one pointing to the classes12.jar for the
oracle8i and other pointing to the ojdbc14.jar for oracle10g.
Then you deploy one application that uses both datasources.
Then you have some Driver extension code in your application that should
extend the oracle10g driver... How your application classloader will be able
to resolve wich driver it¹s going to load?

Regards,
Daniel 


On 19/4/07 21:41, "David Jencks" <[EMAIL PROTECTED]> wrote:

> I don't seem to be explaining what I have in mind very well.  I was thinking
> of a text entry box on the db wizard page where you;d type in a fully
> qualified class name and a button you'd then push, at which point only jars
> containing that class would appear in the list of jars. You could then select
> the one you want as a dependency of the plan you are constructing.   I don't
> understand the purpose of the class you show below.
> 
> So for instance you could type in "com.foo.BarXADataSourceImpl" and you'd get
> a list of all the different FooBar db driver jars.
> 
> thanks
> david jencks
> 
> On Apr 19, 2007, at 9:58 AM, Daniel Alheiros wrote:
> 
>>  Interesting... 
>>  
>>  So if my application depends on an OracleDriver or other vendor specific
>> implementations how my application will be instructed to refer to the
>> specific implementation (jar) as my class import one of those. How can it
>> resolve the reference to the correct jar?
>>  
>>  An example class:
>>  import java.sql.Connection; import java.sql.Driver; import
>> java.sql.DriverManager; import java.sql.SQLException; import
>> oracle.jdbc.OracleDriver; /** * @author daniel */ public class WeirdTest {
>>    /** * @param args */    public static void main(String[] args)
>>    {    try    {    Driver driver = new OracleDriver();
>>    DriverManager.registerDriver(driver);    Connection conn =
>> DriverManager.getConnection("jdbc:oracle:thin:@noldb03:1521:cpslive",
>> "nol_web_page_builder", "nolwebpagebuilder");
>>    System.out.println(conn.getMetaData());    }    catch
>> (SQLException e)    {    e.printStackTrace();    }     } }
>>  Regards
>>  
>>  
>>  On 19/4/07 15:51, "David Jencks" <[EMAIL PROTECTED]> wrote:
>>  
>>>  > 
>>>  > On Apr 19, 2007, at 2:08 AM, Daniel Alheiros wrote:
>>>  > 
  >> Sorry for the ignorance, but I'm a but confused about this jar  
  >> selection...
  >> Does it allows me to have more than one driver version for the same  
  >> vendor
  >> (like having a Oracle 8i and Oracle 10g drivers at same time being  
  >> used by
  >> different datasources)?
>>>  > 
>>>  > yes.
>>>  > 
  >> If not, what is the point in selecting the JAR in
  >> this form?
  >> 
  >> Does the Geronimo's classloaders allows me to have "one" class in  
  >> different
  >> versions available? I don't believe it could be managed safely, so  
  >> I believe
  >> it doesn't.
>>>  > 
>>>  > not in the same classloader, but just as with the datasources this  
>>>  > works fine with the "same" class in different classloaders.
  >> 
  >> I like the idea of having a list containing eventual implementation  
  >> options,
  >> because it is much easier to take a look in an existing environment  
  >> and be
  >> aware of what drivers are available and avoid eventual  
  >> incompatibilities
  >> changing drivers (like Oracle 8i and Oracle 9 or 10g drivers)
>>>  > 
>>>  > Collecting the jars needed for a particular driver to work can't be  
>>>  > done in any automatic uniform way at the moment AFAIK.  So we either  
>>>  > have to show all the jars and let the user pick or require that some  
>>>  > person figure out and install the metadata for each driver.  My  
>>>  > experience is that a metadata based solution will never be kept up to  
>>>  > date.
>>>  > 
>>>  > I thought that a search feature that would find all the jars  
>>>  > containing a particular class, given the fully qualified class name,  
>>>  > was a reasonable compromise between having to look through all the  
>>>  > jars with no clue about whats inside and hiding most of the jars  
>>>  > based on what is sure to be out of date information.
>>>  > 
>>>  > thanks
>>>  > david jencks
>>>  > 
  >> 
  >> Regards
  >> 
  >> 
  >> On 18/4/07 19:28, "Aaron Mulder" <[EMAIL PROTECTED]>  
  >> wrote:
  >> 
>  >>> Just remember that one of the main reasons that there's an awkward
>  >>> display of tons of JARs now is that the DB2 driver (did?  does?)
>  >>> require 3 JARs to al

Re: tld version issue

[jira] Updated: (GERONIMO-3109) struts-nested.tld conversion error

[RESULT][VOTE] Release XBean 3.0

[jira] Resolved: (GERONIMO-2730) JAX-RPC EJB Web Services support appears to be broken

[jira] Created: (GERONIMO-3109) struts-nested.tld conversion error

Re: [VOTE] Release XBean 3.0

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

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

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

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

Re: AppClient security call back handlers essentially broken in 2.0

[jira] Commented: (GERONIMO-3108) Deploy fails when a WAR is deployed having a CSS file with special character

[jira] Created: (GERONIMO-3108) Deploy fails when a WAR is deployed having a CSS file with special character

Re: Running multiple instances of geronimo

Re: AppClient security call back handlers essentially broken in 2.0

Re: Running multiple instances of geronimo

AppClient security call back handlers essentially broken in 2.0

Re: Running multiple instances of geronimo

Re: [jira] Commented: (GERONIMO-3106) When you are in the Create Database Pool wizard the jar driver list could show only jars containing Driver implementations

19 matches

Site Navigation

Mail list logo

Footer information