date:20081016

Re: svn commit: r704975 - in /geronimo/gshell/trunk: gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/

2008-10-16 Thread Guillaume Nodet

Looks good, I can work on fixing that if you want.

On Fri, Oct 17, 2008 at 8:23 AM, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Yes, I suppose the PluginParser can set this, and thus avoid needing to make
> it part of the Command intf.
>
> --jason
>
>
> On Oct 16, 2008, at 2:33 PM, Guillaume Nodet wrote:
>
>> Yeah, I was supposing so.
>> However, it seems more natural, as the only place where the location
>> is set is when registering the command in the registry.
>> Maybe another way would be to say that the location has to be set on
>> the command in some way before registering it: the registry would
>> retrieve the location from the command instead of receiving it as an
>> argument to the registerCommand method and then setting the location.
>> As the same command object can not be registered at two different
>> locations (else one location would be somehow lost on the command), it
>> may make sense.  The location could be set directly when the
>> PluginParser creates the bean definition.  Wdyt ?
>>
>> On Thu, Oct 16, 2008 at 9:24 AM, Jason Dillon <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> I didn't really want to expose setLocation in Command, hence the reason
>>> why
>>> it was coded like that.
>>>
>>> --jason
>>>
>>>
>>> On Oct 16, 2008, at 1:04 AM, [EMAIL PROTECTED] wrote:
>>>
 Author: gnodet
 Date: Wed Oct 15 11:04:24 2008
 New Revision: 704975

 URL: http://svn.apache.org/viewvc?rev=704975&view=rev
 Log:
 Remove an ugly cast by adding the setLocation method to the Command
 interface

 Modified:


 geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java


 geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java

 Modified:

 geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
 URL:

 http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java?rev=704975&r1=704974&r2=704975&view=diff


 ==
 ---

 geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
 (original)
 +++

 geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
 Wed Oct 15 11:04:24 2008
 @@ -31,6 +31,8 @@
 {
  CommandLocation getLocation();

 +void setLocation(CommandLocation location);
 +
  /**
   * Returns the action of the command.
   *

 Modified:

 geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
 URL:

 http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java?rev=704975&r1=704974&r2=704975&view=diff


 ==
 ---

 geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
 (original)
 +++

 geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
 Wed Oct 15 11:04:24 2008
 @@ -60,9 +60,7 @@
  throw new DuplicateCommandException(name);
  }

 -if (command instanceof CommandSupport) {
 -((CommandSupport)command).setLocation(new
 CommandLocationImpl(name));
 -}
 +command.setLocation(new CommandLocationImpl(name));

  commands.put(name, command);



>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> 
>> Blog: http://gnodet.blogspot.com/
>> 
>> Open Source SOA
>> http://fusesource.com
>
>



-- 
Cheers,
Guillaume Nodet

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

Open Source SOA
http://fusesource.com

[jira] Commented: (GERONIMO-4366) Non-ASCII chars in deployment plan xml files cause deployment failed with NPE on deployment time

2008-10-16 Thread Forrest Xia (JIRA)


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

Forrest Xia commented on GERONIMO-4366:
---

Yep, the line like "" embedded in some deployment plan is 
evaluated  to  the values of my local system when checking out, that causes 
some deployment plans include non-ASCII chars, and lead to this finding.

Seems this jira more like a feature request, right? Is it possible to have time 
investigating on this? Since adding non-english comments are common to 
developers in non-english countries :-)

If you think it's not a real bug, you can close it. thanks!

> Non-ASCII chars in deployment plan xml files cause deployment failed with NPE 
> on deployment time
> 
>
> Key: GERONIMO-4366
> URL: https://issues.apache.org/jira/browse/GERONIMO-4366
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1.3
> Environment: Any platforms
>Reporter: Forrest Xia
>
> Steps to recur:
> 1. checkout AG samples 2.1.2
> 2. build them
> 3. install jms-mdb-xxx.ear with plan 
> "samples\jms-mdb\jms-mdb-tomcat\target\resources\META-INF\plan.xml" in admin 
> console
> You will get an NPE like this:
> java.lang.NullPointerException
> org.apache.geronimo.common.DeploymentException: java.lang.NullPointerException
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:275)
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:618)
>   at 
> org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
>   at 
> org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
>   at 
> org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
>   at java.lang.Thread.run(Thread.java:810)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.geronimo.deployment.CopyResourceContext.addFile(CopyResourceContext.java:144)
>   at 
> org.apache.geronimo.deployment.DeploymentContext.addFile(DeploymentContext.java:461)
>   at 
> org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.installModule(AbstractWebModuleBuilder.java:289)
>   at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.installModule(SwitchingModuleBuilder.java:153)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:586)
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
>   ... 12 more
> To remove it, update all deployment plan files to remove any non-ascii chars, 
> then rebuild and redeploy through admin console, it works! 
> So I doubt AG does not support any non-ASCII chars in deployment plan. 
> But for non-english environment, user might leave some comments including 
> non-english chars in deployment plan, so it's necessary to take time to make 
> our deployment plan could contain non-ASCII chars.

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

Re: svn commit: r704975 - in /geronimo/gshell/trunk: gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/

2008-10-16 Thread Jason Dillon

Yes, I suppose the PluginParser can set this, and thus avoid needing  
to make it part of the Command intf.


--jason


On Oct 16, 2008, at 2:33 PM, Guillaume Nodet wrote:


Yeah, I was supposing so.
However, it seems more natural, as the only place where the location
is set is when registering the command in the registry.
Maybe another way would be to say that the location has to be set on
the command in some way before registering it: the registry would
retrieve the location from the command instead of receiving it as an
argument to the registerCommand method and then setting the location.
As the same command object can not be registered at two different
locations (else one location would be somehow lost on the command), it
may make sense.  The location could be set directly when the
PluginParser creates the bean definition.  Wdyt ?

On Thu, Oct 16, 2008 at 9:24 AM, Jason Dillon  
<[EMAIL PROTECTED]> wrote:
I didn't really want to expose setLocation in Command, hence the  
reason why

it was coded like that.

--jason


On Oct 16, 2008, at 1:04 AM, [EMAIL PROTECTED] wrote:


Author: gnodet
Date: Wed Oct 15 11:04:24 2008
New Revision: 704975

URL: http://svn.apache.org/viewvc?rev=704975&view=rev
Log:
Remove an ugly cast by adding the setLocation method to the Command
interface

Modified:

geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/ 
gshell/command/Command.java


geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/ 
java/org/apache/geronimo/gshell/wisdom/registry/ 
CommandRegistryImpl.java


Modified:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/ 
gshell/command/Command.java

URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java?rev=704975&r1=704974&r2=704975&view=diff

= 
= 
= 
= 
= 
= 
= 
= 
= 
= 


---
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/ 
gshell/command/Command.java

(original)
+++
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/ 
gshell/command/Command.java

Wed Oct 15 11:04:24 2008
@@ -31,6 +31,8 @@
{
  CommandLocation getLocation();

+void setLocation(CommandLocation location);
+
  /**
   * Returns the action of the command.
   *

Modified:
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/ 
java/org/apache/geronimo/gshell/wisdom/registry/ 
CommandRegistryImpl.java

URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java?rev=704975&r1=704974&r2=704975&view=diff

= 
= 
= 
= 
= 
= 
= 
= 
= 
= 


---
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/ 
java/org/apache/geronimo/gshell/wisdom/registry/ 
CommandRegistryImpl.java

(original)
+++
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/ 
java/org/apache/geronimo/gshell/wisdom/registry/ 
CommandRegistryImpl.java

Wed Oct 15 11:04:24 2008
@@ -60,9 +60,7 @@
  throw new DuplicateCommandException(name);
  }

-if (command instanceof CommandSupport) {
-((CommandSupport)command).setLocation(new
CommandLocationImpl(name));
-}
+command.setLocation(new CommandLocationImpl(name));

  commands.put(name, command);










--
Cheers,
Guillaume Nodet

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

Open Source SOA
http://fusesource.com

Re: Continuous TCK Testing

2008-10-16 Thread Jason Dillon

Yup, might need to resurrect that stuff if we plan on using it again.

--jason

On Oct 16, 2008, at 10:39 PM, Jason Warner wrote:

Whoops... just realized that this was actually removed and I was
looking at a stickied revision of viewVC. Nevermind.

On Thu, Oct 16, 2008 at 11:15 AM, Jason Warner <[EMAIL PROTECTED]>
wrote:
While we wait to hear back in regards to the license, I'm going to
update the maven used in build-support. The server now requires
2.0.9 and the version currently used by build support is 2.0.5. I
suppose we'll need to update ant, as well. What version of ant
should we be using? 1.7.1?

On Fri, Oct 10, 2008 at 11:25 AM, Kevan Miller
<[EMAIL PROTECTED]> wrote:

On Oct 8, 2008, at 11:56 PM, Kevan Miller wrote:

On Oct 8, 2008, at 4:31 PM, Jason Warner wrote:

We had some suggestions earlier for some alternate means of
implementing this (Hudson, Conitnuum, etc...). Now that we've had
Jason Dillon provide an overview of what we had in place before,
does anyone have thoughts on what we should go with? I'm thinking
we should stick with the AHP based solution. It will need to be
updated most likely, but it's been tried and tested and shown to
meet our needs. I'm wondering, though, why we stopped using it
before. Was there a specific issue we're going to have to deal
with again?

IIRC, the overwhelming reason we stopped using it before was
because of hosting issues -- spotty networking, hardware failures,
poor colo support, etc. We shouldn't have any of these problems,
now. If we do run into problems, they should now be fixable. I have
no reason to favor Hudson/Continuum over AHP. So, if we can get AHP
running easily, I'm all for it. There's only one potential issue,
that I'm aware of.

We previously had an Open Source License issued for our use of
Anthill. Here's some of the old discussion -- http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902

Although the board was aware of our usage of AntHill, since we
weren't running AntHill on ASF hardware, I'm not sure the license
was fully vetted by Infra. I don't see any issues, but I'll want to
run this by Infra.

Jason D, will the existing license cover the version of AntHill
that we'll want to use? I'll run the license by Infra and will also
describe the issue for review by the Board, in our quarterly report.

46 matches

Mail list logo