Re: dojo-tomcat/jetty6

2008-10-13 Thread Ivan 
After running mvn install on my local svn folder, I checked the file
dojo-tomcat-2.2-SNAPSHOT.car in the target folder, it has the same structure
with the previous one.

---dojo---dojo
 ---dijit
---WEB-INF
---MENTA-INF

Adding the web context "dojo", I guess we still need
/dojo/dojo/dojo/dojo.js, have I missed anything ?


2008/10/14 Jay D. McHugh <[EMAIL PROTECTED]>

> Ivan,
>
> Have you had a chance to try a newer snapshot?
>
> Is Dojo showing up in the correct location for you?
>
> Jay
>
> Ivan wrote:
> > Just find in the newest snapshot, after I manually install the dojo
> plugin,
> > it has an extra folder "dojo", currently when we want the refer to
> dojo.js,
> > the url will be /dojo/dojo/dojo/dojo.js.
> > I suggest to repackage the dojo-mini.zip file.
> >
> >
> > 2008/10/8 Lin Sun <[EMAIL PROTECTED]>
> >
> >> Hi Manu, Ok, making it optional sounds good.
> >>
> >> Lin
> >>
> >> On Wed, Oct 8, 2008 at 8:24 AM, Manu George <[EMAIL PROTECTED]>
> >> wrote:
> >>> Hi Lin,
> >>>
> >>> I am using it in the EjbServer Portlet I am developing. But I guess
> >>> that it can also be made an optional console plugin
> >>>
> >>> Regards
> >>> Manu
> >>>
> >>> On Wed, Oct 8, 2008 at 1:43 AM, Lin Sun <[EMAIL PROTECTED]> wrote:
>  Jay,
> 
>  Right, I don't know how far that work went either.
> 
>  Thus, I didn't include the dojo-tomcat/jetty6 in the new
>  javaee5-tomcat/jetty plugin group(profile), which will be used to
>  build the javaee5 assemblies.
> 
>  Lin
> 
>  n Tue, Oct 7, 2008 at 3:41 PM, Jay D. McHugh <[EMAIL PROTECTED]>
> >> wrote:
> > Lin,
> >
> > Someone was working on upgrading the views in Geronimo to use the
> > widgets in the new version of Dojo.  I don't know how far that work
> >> went.
> > So, I believe you are correct that the legacy set are the only ones
> >> that
> > are currently in use.
> >
> > Jay
> >
> > Lin Sun wrote:
> >> I think these two portlets are using the dojo-legacy-tomcat/jetty6.
> >> Nothing except the javaee5 assemblies lists dojo-tomcat/jetty6 as
> >> dependency.
> >>
> >> Lin
> >>
> >> On Tue, Oct 7, 2008 at 3:10 PM, Donald Woods <[EMAIL PROTECTED]>
> >> wrote:
> >>> I believe only the Debug Views and Plan Creator portlets need Dojo
> >> right
> >>> now, which I'm going to remove from the JEE5 assemblies and let
> users
> >>> optionally install them, once I've updated the Welcome portlet to
> >> include
> >>> some information about what optional Console plugins are
> >> available
> >>>
> >>> -Donald
> >>>
> >>>
> >>> Lin Sun wrote:
>  Hi,
> 
>  I don't see dojo-tomcat/jetty6 is used by admin console right now
> in
>  trunk thus I plan to remove it from the javaee5 assembly.   Any
>  objection?
> 
>  Whenever we have converted some of our admin console to use
>  dojo-tomcat/jetty6, dojo-tomcat/jetty6 should be automatically
> >> pulled
>  into javaee5 assembly via transitive dependency, similar like
>  dojo-legacy-tomcat/jetty6 today.
> 
>  Lin
> 
> >
> >
> >
>



-- 
Ivan

Jetty Security refactoring for JASPI

2008-10-13 Thread David Jencks 
Greg and Jan were kind enough to create a branch for me to play around  
with a JASPI (Java Authentication Service Provider Interface)  
integration with jetty and its getting to a point where I'm willing to  
talk about it.


Code is at https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi

JASPI attempts to provide a uniform framework for messaging systems,  
both client and server side, to plug in message authentication.  On  
the client you can add auth info to a request and validate auth info  
on a response.  On the server you can validate auth info on a request  
and add auth info to a response.  The auth code can conduct arbitrary  
message exchanges to negotiate what info is needed and transmit the  
info.  I've been working on the server side auth for jetty.


The actual spec jaspi interfaces are not 100% ideal for http and don't  
allow stuff like lazy authentication for unsecured resources so I've  
come up with interfaces similar in spirit to the jaspi ones.


I've also tried to rework the implementation so it is more friendly to  
integration with other app servers with their own ideas about security  
frameworks such as geronimo and in particular make jacc  
implementations easier. I expect these changes will also simplify  
integration with e.g. jboss and glassfish but I haven't seriously  
tried to verify this.


Currently all the authentication code (replacing the *Authenticator  
classes) is implemented in terms of jaspi but I plan to change this  
soon to use the jetty specific interfaces directly.


So lets follow a HttpServletRequest/Response pair on its voyage  
through the security system...



... it arrives at AbstractSecurityHandler.handle.  This is a template  
method that runs through the following structure calling out to  
subclasses and the authentication system:
1. calls checkUserDataPermissions(pathInContext, base_request,  
base_response, constraintInfo).  This checks the user data  
constraints, basically that the request arrived over the right kind of  
connection (http/https).  Two obvious implementations of this are the  
existing jetty constraint based implementation or one based on JACC.


2. calls isAuthMandatory(base_request, base_response, constraintInfo)  
to determine if the request actually needs authentication.  If it does  
not we can often delay authentication until a method relying on auth  
results is called (such as getUserPrincipal or isUserInRole).  Again  
this can be implemented using constraints or JACC.


3. packs the request, response, and authManditory into a  
JettyMessageInfo holder object which can also pass various auth info  
in a map.


4. delegates the authentication to the jaspi-like ServerAuthResult  
authResult = serverAuthentication.validateRequest(messageInfo);


  assuming we are not doing lazy auth, this will extract the  
credentials from the request (possibly conducing a multi-message  
exchange with the client to request the credentials) and validate them.
  Validation can use a LoginService possibly provided to the  
ServerAuthentication which could be JAAS, Hash, JDBC, etc etc.
  Lazy auth results in returning a lazy result that only attempts  
authentication when info is actually needed.  In this case no message  
exchange with the client is possible.


5. Assuming that authentication succeeded (this includes the lazy case  
where the request would be allowed even without authentication), we  
wrap up the result in an identity delegate:

 UserIdentity userIdentity = newUserIdentity(authResult);
 base_request.setUserIdentity(userIdentity);
The UserIdentity is the delegate for run-as role implementation and  
actually answering auth questions from the application program.  This  
allows app servers to handle run-as roles however they want.


6. Assuming authentication is mandatory, now that we know the user, we  
can find out if they are in the appropriate roles:
checkWebResourcePermissions(pathInContext, base_request,  
base_response, constraintInfo, userIdentity)


7. On success, we can actually handle the request:
getHandler().handle(pathInContext, messageInfo.getRequestMessage(),  
messageInfo.getResponseMessage(), dispatch);


8. Assuming no exceptions were thrown, we can now secure the response  
(normally a no-op for http):

serverAuthentication.secureResponse(messageInfo, authResult);

---

JASPI implementations

I wrote a fairly complete jaspi framework implementation for geronimo  
(rather than the bits actually needed for http which I wrote for  
jetty) and have a nearly-untested openid implementation.   This  
(theoretically) lets you openid-enable your app by supplying an  
appropriate login page and useing the openid auth module.


Theres also a glassfish implementation that I haven't looked at and  
someone wrote a SPNEGO auth module that works with it.  http://spnego.ocean.net.au/


--

Re: Framework assembly problems with commands

2008-10-13 Thread Jarek Gawor 
Comments inline:

On Mon, Oct 13, 2008 at 4:39 PM, Joe Bohn <[EMAIL PROTECTED]> wrote:
> It seems that a number of the commands stopped working on the framework
> assembly sometime between the release of 2.1.1 and 2.1.2.   The problem
> persists in 2.1.3, branches/2.1, and trunk.
>
> These are problems using the shell/batch commands.  I know we want to move
> over completely to gshell ... but shouldn't these still be working now?
>  There are no gshell equivalents for some of these (such as search-plugins).

All these commands have GShell equivalents but they just might be
named slightly differently (e.g. seach-plugins == list-plugins).
However, the GShell equivalents might not support all the features of
the commands (e.g. --offline is not supported in GShell).

> Commands such as search-plugins, list-targets, list-modules, and perhaps
> others result in the following error:
>
> Using GERONIMO_BASE:   /Users/bohn/g-images/2.1.2/geronimo-framework-2.1.2
> Using GERONIMO_HOME:   /Users/bohn/g-images/2.1.2/geronimo-framework-2.1.2
> Using GERONIMO_TMPDIR: var/temp
> Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home
> org.apache.geronimo.kernel.GBeanNotFoundException: No GBeans found:
> [?#org.apache.geronimo.kernel.util.Main]
>at
> org.apache.geronimo.kernel.basic.BasicRegistry.getGBeanInstance(BasicRegistry.java:153)
>at
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:286)
>at
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:282)
>at
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:100)
>at
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:59)
>at
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
>at
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
>at
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
>
> Any pointers?  That's all there really is.  There's nothing in the logs.

If basic deployment should work in the framework assembly we must also
install "jsr88-cli" and "offline-deployer" plugins. Once I installed
these plugins I was able to do list-targets, list-modules. I have not
tried to deploy a new plugin though.

Jarek

Re: [DISCUSS] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Jarek Gawor 
On Mon, Oct 13, 2008 at 1:02 PM, Joe Bohn <[EMAIL PROTECTED]> wrote:
>
> One more question:  Has any tck validation been performed for this updated
> spec?
>

Yes. Geronimo trunk was updated to use the SNAPSHOT of the spec with
the fix and so TCK was/is running with it.

Jarek

Re: [VOTE] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Joe Bohn 

+1 assuming we're still OK with TCK.

Joe


Jarek Gawor wrote:

Hi,

This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one
change from version 1.0.0:

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

Staging repo:
http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/

Staging site:
http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/

The vote is open until Thursday (October 16th).

[ ] +1
[ ] +0
[ ] -1

Jarek

Framework assembly problems with commands

2008-10-13 Thread Joe Bohn 
It seems that a number of the commands stopped working on the framework 
assembly sometime between the release of 2.1.1 and 2.1.2.   The problem 
persists in 2.1.3, branches/2.1, and trunk.


These are problems using the shell/batch commands.  I know we want to 
move over completely to gshell ... but shouldn't these still be working 
now?  There are no gshell equivalents for some of these (such as 
search-plugins).


Commands such as search-plugins, list-targets, list-modules, and perhaps 
others result in the following error:


Using GERONIMO_BASE:   /Users/bohn/g-images/2.1.2/geronimo-framework-2.1.2
Using GERONIMO_HOME:   /Users/bohn/g-images/2.1.2/geronimo-framework-2.1.2
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home
org.apache.geronimo.kernel.GBeanNotFoundException: No GBeans found: 
[?#org.apache.geronimo.kernel.util.Main]
	at 
org.apache.geronimo.kernel.basic.BasicRegistry.getGBeanInstance(BasicRegistry.java:153)
	at 
org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:286)
	at 
org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:282)
	at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:100)
	at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:59)
	at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)

at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at 
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)

Any pointers?  That's all there really is.  There's nothing in the logs.

I guess we haven't had anybody testing installing plugins into the 
framework recently ...



Thanks,
Joe

Re: An idea for defining custom valves in config.xml

2008-10-13 Thread Jason Warner 
On Wed, Oct 8, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 8, 2008, at 1:55 PM, Joe Bohn wrote:
>
>  Jason Warner wrote:
>>
>>> Thanks for the explanation, David.  I don't disagree with anything you've
>>> explained, but I'm not sure you've addressed my concern about the disparity
>>> in the effort required to deploy a custom valve on tomcat and on geronimo.
>>>  Even with the a streamlined process involving a tomcat server portlet and
>>> using the tomcat6 plugin as a base, the user still has to become a plugin
>>> developer to deploy their valve on geronimo.  If that's how it has to be,
>>> then I suppose that's how it has to be.  I'm just concerned that it could
>>> turn off users that might have otherwise lived happily with geronimo.  I'm
>>> not really sure how widespread the use of custom valves are, though, so
>>> maybe it's just a small minority this would even effect.  I'd be curious to
>>> get some feedback from some other developers and see if they have any
>>> thoughts on the matter.  Anyone else out there keeping an eye on this
>>> thread?
>>>
>>
>> I've been keeping an eye on it and I agree with you Jason that there is a
>> disparity in the work required to add a valve to tomcat versus that required
>> to add a valve to tomcat embedded in Geronimo.  I also agree with David that
>> the current Tomcat process does not lend itself to a reproducible
>> configuration.
>>
>> In cases like this I tend to think like a politician and advocate a
>> both/and rather than an either/or.  I suspect that some users will want
>> things in Geronimo to be as similar to Tomcat as possible ... and so will
>> want a simple configuration solution.  Doing so might convince them to move
>> over to Geronimo and over time they may gain a greater appreciation for a
>> more Geronimo like solution.  Others might be coming in with more knowledge
>> of Geronimo and expect something that is more consistent with Geronimo and
>> can be reproduced.  Can we give them both what they want?
>>
>> It seems like we could help the Tomcat centric folks with a simple
>> configuration attribute that we can use to extend the classpath.  For the
>> more sophisticated Geronimo user we can direct them to rebuild/redeploy the
>> Tomcat module with the additional dependency on the valve jar ... perhaps
>> using c-m-p and then their own custom assembly. Even while providing the
>> first approach we can highly recommend the second approach.
>>
>> It seems to me that the attribute/classpath extension is a simple thing to
>> implement and will provide a high level of value to users that are
>> accustomed to Tomcat.  The Tomcat module rebuild/redeploy is just a matter
>> of documentation ... correct?
>>
>
> I guess I'm trying to argue that we should be making doing the "right
> thing" as easy as modifying tomcat to have a custom valve.
>
> I'm not convinced we're all that far off:
>
> tomcat -stop server
> geronimo - server restart may be needed later.
>
> tomcat - add jar to server/lib (?)
> geronimo - add jar to repository
>
> tomcat - edit server.xml
> geronmo -edit tomcat6 plam.xml
>
> geronimo - add artifact-alias (this could probably be automated into part
> of the next step).  Basically this should be editing the
> geronimo-plugin.xml.
> geronimo - deploy modified tomcat6 plan.xml, resulting in a new plugin.


I seem to be having issues with this step.  It's probably something I'm
doing, though.  Is there a good example of the artifact-alias element in
action?  My issue seems to be that I can't disable the tomcat6 plugin
because modules that are dependent upon it restart it automatically when the
server is started.  At least, this is what I believe is happening.  This
results in port conflicts and such when my custom tomcat6 module is
started.  Shouldn't the artifact-alias be pointing the dependent modules to
the  custom module instead of the default tomcat6 plugin?  If not, perhaps
that's functionality we should add.  It's possible I'm specifying the
artifact-alias incorrectly or in the wrong place, which is why I'm asking
for an example where this is done.  I see it mentioned a few times in the
documentation, but it's usually either out of context or not detailed
enough.

Thanks!


>
> tomcat - restart
> geronimo - restart tomcat-dependent plugins/apps
>
>
> There's basically only one more step in geronimo.  I'm not sure how well
> the "obsoletes" functionality works at the moment but ideally we could have
> the new plugin obsolete the original and so installing it would shut down
> the old one, shut down the plugins depending on it, and restart the
> dependencies after install.  This is the same number of steps.
>
> One missing bit here is that there is no good way to deploy an app with an
> external geronimo-plugin.xml to end up immediately with a plugin.
>
> thanks
> david jencks
>
>
>
>
>
>>
>> Joe
>>
>>  On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <[EMAIL PROTECTED]>> [EMAIL PROTECTED]>> wrote:
>>>   On Oct 8

Re: dojo-tomcat/jetty6

2008-10-13 Thread Jay D. McHugh 
Ivan,

Have you had a chance to try a newer snapshot?

Is Dojo showing up in the correct location for you?

Jay

Ivan wrote:
> Just find in the newest snapshot, after I manually install the dojo plugin,
> it has an extra folder "dojo", currently when we want the refer to dojo.js,
> the url will be /dojo/dojo/dojo/dojo.js.
> I suggest to repackage the dojo-mini.zip file.
> 
> 
> 2008/10/8 Lin Sun <[EMAIL PROTECTED]>
> 
>> Hi Manu, Ok, making it optional sounds good.
>>
>> Lin
>>
>> On Wed, Oct 8, 2008 at 8:24 AM, Manu George <[EMAIL PROTECTED]>
>> wrote:
>>> Hi Lin,
>>>
>>> I am using it in the EjbServer Portlet I am developing. But I guess
>>> that it can also be made an optional console plugin
>>>
>>> Regards
>>> Manu
>>>
>>> On Wed, Oct 8, 2008 at 1:43 AM, Lin Sun <[EMAIL PROTECTED]> wrote:
 Jay,

 Right, I don't know how far that work went either.

 Thus, I didn't include the dojo-tomcat/jetty6 in the new
 javaee5-tomcat/jetty plugin group(profile), which will be used to
 build the javaee5 assemblies.

 Lin

 n Tue, Oct 7, 2008 at 3:41 PM, Jay D. McHugh <[EMAIL PROTECTED]>
>> wrote:
> Lin,
>
> Someone was working on upgrading the views in Geronimo to use the
> widgets in the new version of Dojo.  I don't know how far that work
>> went.
> So, I believe you are correct that the legacy set are the only ones
>> that
> are currently in use.
>
> Jay
>
> Lin Sun wrote:
>> I think these two portlets are using the dojo-legacy-tomcat/jetty6.
>> Nothing except the javaee5 assemblies lists dojo-tomcat/jetty6 as
>> dependency.
>>
>> Lin
>>
>> On Tue, Oct 7, 2008 at 3:10 PM, Donald Woods <[EMAIL PROTECTED]>
>> wrote:
>>> I believe only the Debug Views and Plan Creator portlets need Dojo
>> right
>>> now, which I'm going to remove from the JEE5 assemblies and let users
>>> optionally install them, once I've updated the Welcome portlet to
>> include
>>> some information about what optional Console plugins are
>> available
>>>
>>> -Donald
>>>
>>>
>>> Lin Sun wrote:
 Hi,

 I don't see dojo-tomcat/jetty6 is used by admin console right now in
 trunk thus I plan to remove it from the javaee5 assembly.   Any
 objection?

 Whenever we have converted some of our admin console to use
 dojo-tomcat/jetty6, dojo-tomcat/jetty6 should be automatically
>> pulled
 into javaee5 assembly via transitive dependency, similar like
 dojo-legacy-tomcat/jetty6 today.

 Lin

> 
> 
>

[jira] Commented: (GERONIMO-4352) IMAP provider: accessing parts of a multipart/mixed message causes invalid command

2008-10-13 Thread Andreas Veithen (JIRA) 

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

Andreas Veithen commented on GERONIMO-4352:
---

I think that the patch causes a regression elsewhere, but I need to analyze 
this further. I will try to come up with some simple test cases that provide 
evidence for this.

> IMAP provider: accessing parts of a multipart/mixed message causes invalid 
> command
> --
>
> Key: GERONIMO-4352
> URL: https://issues.apache.org/jira/browse/GERONIMO-4352
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Andreas Veithen
>Assignee: Rick McGuire
> Attachments: 03-javamail.log, GERONIMO-4352.diff
>
>
> When accessing the content of the second part of a multipart/mixed message 
> (see attachment), the following IMAP command is sent:
> FETCH 1 (BODY.PEEK[2.TEXT])
> This results in an error (FETCH failed). IMAP server is GreenMail: 
> http://www.icegreen.com/greenmail/
> RFC3501 says about the TEXT part specifier:
>  The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
>  specifiers can be the sole part specifier or can be prefixed by
>  one or more numeric part specifiers, provided that the numeric
>  part specifier refers to a part of type MESSAGE/RFC822.  The
>  MIME part specifier MUST be prefixed by one or more numeric
>  part specifiers.
> Since the second part is not message/rfc822, the command issued is incorrect. 
> I believe that the correct command in this case should be:
> FETCH 1 (BODY.PEEK[2])

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

Re: [VOTE] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Rick McGuire 

+1

Jarek Gawor wrote:

Hi,

This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one
change from version 1.0.0:

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

Staging repo:
http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/

Staging site:
http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/

The vote is open until Thursday (October 16th).

[ ] +1
[ ] +0
[ ] -1

Jarek

Look out for build problems related to jetty7

2008-10-13 Thread David Jencks 
I just updated my jetty7 integration in the sandbox and committed some  
minor changes in the trunk build to make it easier to switch between  
jetty6 and jetty7 in rev 704183.  I introduced a new property

jetty6

that can be switched to jetty7 and used it in all the poms as a  
variable whenever one or the other is needed, including in some  
 elements.


I don't see any problems from this but I might have missed something.   
Keep your eyes open and we can revert this if it causes problems.


If you want to try out the jetty7 support you need to build the https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi 
 jetty branch, the jetty7 integration in https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/jetty7 
, and patch trunk with https://issues.apache.org/jira/secure/attachment/12392024/jetty-6-to-7-v2.patch



thanks
david jencks

[jira] Updated: (GERONIMO-4249) Integrate jetty7 (servlet 3.0) with jaspi support

2008-10-13 Thread David Jencks (JIRA) 

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

David Jencks updated GERONIMO-4249:
---

Attachment: jetty-6-to-7-v2.patch

Updated jetty6 to jetty7 patch.

> Integrate jetty7 (servlet 3.0) with jaspi support
> -
>
> Key: GERONIMO-4249
> URL: https://issues.apache.org/jira/browse/GERONIMO-4249
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Jetty
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
> Attachments: jetty-6-to-7-v2.patch, jetty-6-to-7.patch
>
>
> I've been working on a jetty7 jaspi implementation and integrating this in 
> geronimo.  The main code is at 
> https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/jetty7
> I'll attach a patch to the main build so the jetty7 plugins get used instead 
> of the jetty6 plugins.

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

[jira] Commented: (GERONIMO-4354) Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar when starting Geronimo 2.1.1 on Solaris 10 x86

2008-10-13 Thread Jarek Gawor (JIRA) 

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

Jarek Gawor commented on GERONIMO-4354:
---

What does tar --version return? It should say GNU somewhere in the output. If 
not, either get the GNU tar or download the zip file and follow the steps I 
mentioned before.


> Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar 
> when starting Geronimo 2.1.1 on Solaris 10 x86
> --
>
> Key: GERONIMO-4354
> URL: https://issues.apache.org/jira/browse/GERONIMO-4354
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: installer
>Affects Versions: 2.1.1
> Environment: uname -a
> SunOS bremy 5.10 Generic_127128-06 i86pc i386 i86pc
>Reporter: Pierre-Antoine Berreur
>Priority: Blocker
>
> Can not start geronimo after unzipping it on Solaris 10.
> [EMAIL PROTECTED] /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1$ 
> ./bin/geronimo.sh run
> Using GERONIMO_BASE:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
> Using GERONIMO_HOME:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
> Using GERONIMO_TMPDIR: var/temp
> Using JRE_HOME:/usr/java/jre
> 03:23:39,177 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car"
> org.apache.geronimo.kernel.repository.MissingDependencyException: Missing 
> dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar
> at 
> org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113)
> at 
> org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:405)
> at 
> org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322)
> at 
> org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267)
> 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.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:203)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
> java.lang.IllegalStateException: GBean is not running: 
> org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:205)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:

Re: [DISCUSS] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Lin Sun 
+1

Lin

On Mon, Oct 13, 2008 at 11:19 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
> There are some issues with the maven generated site.  These aren't new
> problems and they are "doc" related ... so I'm not sure if they should
> really hinder the spec release.
>
> I just started looking into them since I had some of the same problems with
> the recent samples 2.1.2 release (BTW ... not all of those issues were
> resolved either before we released).
>
> - The Geronimo banner isn't included.  I think we need to make some updates
> to the spec-parent site.xml (and pom.xml) and do a new release of the
> specs-parent to fix this issue.  However, on my local image some of the same
> changes that I made in samples to resolve this are not providing the same
> magic for specs ... still looking into this.
>
> - There are multiple links in the banner to Geronimo (on the right) and none
> of them take you to the Geronimo home page.  Once again, I think this might
> require some changes to the site.xml in spec-parent to fix it.
>
> Joe
>

Re: [VOTE] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Lin Sun 
+1

Lin

On Mon, Oct 13, 2008 at 10:56 AM, Jarek Gawor <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one
> change from version 1.0.0:
>
>https://issues.apache.org/jira/browse/GERONIMO-4289
>
> Staging repo:
>http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/
>
> Staging site:
>http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/
>
> The vote is open until Thursday (October 16th).
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Jarek
>

Re: [DISCUSS] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Lin Sun 
Sorry...sent to the wrong thread accidentally. ;-(

Lin

On Mon, Oct 13, 2008 at 1:14 PM, Lin Sun <[EMAIL PROTECTED]> wrote:
> +1
>
> Lin
>
> On Mon, Oct 13, 2008 at 11:19 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
>> There are some issues with the maven generated site.  These aren't new
>> problems and they are "doc" related ... so I'm not sure if they should
>> really hinder the spec release.
>>
>> I just started looking into them since I had some of the same problems with
>> the recent samples 2.1.2 release (BTW ... not all of those issues were
>> resolved either before we released).
>>
>> - The Geronimo banner isn't included.  I think we need to make some updates
>> to the spec-parent site.xml (and pom.xml) and do a new release of the
>> specs-parent to fix this issue.  However, on my local image some of the same
>> changes that I made in samples to resolve this are not providing the same
>> magic for specs ... still looking into this.
>>
>> - There are multiple links in the banner to Geronimo (on the right) and none
>> of them take you to the Geronimo home page.  Once again, I think this might
>> require some changes to the site.xml in spec-parent to fix it.
>>
>> Joe
>>
>

Re: Improve geronimo samples use experience

2008-10-13 Thread David Jencks 


On Oct 13, 2008, at 9:47 AM, Lin Sun wrote:


I agree.  It would be nice if we can provide users a downlodable
sample bundle, which contains the prebuilt artifacts and their plans.
This would save users from learning svn, maven and digging around for
the plans.



This seems like a reasonable approach to me.  I think that publishing  
the plans as attached artifacts with a "plan" classifier will be the  
most maven-friendly way to make them available to the assembly plugin  
when putting together this bundle.


I wish we had a way to get a geronimo-plugin.xml into the car file  
when just deploying an app.  That way users could construct a plugin  
equivalent to ours just by deploying the app.  However this might not  
be too easy to do and shouldn't hold up moving forward on some kind of  
bundle.


thanks
david jencks



Lin

On Mon, Oct 13, 2008 at 12:35 PM, Donald Woods <[EMAIL PROTECTED]>  
wrote:

I'd like to see us generate a source + prebuilt artifacts (WAR/EAR +
deployment plans) as a downloadable assembly off our Downloads page.

Requiring users to checkout the Samples source from SVN is not  
friendly to
those that don't have a svn client installed (Windows and some  
default Linux
installs) and requiring them to build the Samples just so they can  
look at
the deployment plans requires more work than most average users  
will be

willing to spend.


-Donald


Joe Bohn wrote:


I too agree that a new user should not need to deal with plugins  
initially

unless they really want to.

I think they can already do this today ... but perhaps not as  
cleanly as

we would like (and not without the user seeing the word "plugin").

The important thing (as David mentioned) is that they need to  
build the
samples first.  I don't think that is an unreasonable request.  In  
fact,
until our recent release of samples, a user had no choice but to  
build the

samples locally as there were no published artifacts.

Once a user has built samples they can do the following if they  
don't want

to leverage the plugins:
- Install any necessary prereqs (such as the sample-datasource).   
There
are a number of ways to do this for the datasource (if  
necessary) 
documented in the wiki.  The easiest is to install the plugin but  
a user

doesn't have to go that route. See
http://cwiki.apache.org/GMOxDOC21/sample-applications.html
- Install the specific sample artifact built locally using the  
archive and

the appropriate plan from the
-tomcat/target/resources/META-INF/plan.xml (or jetty  
equivalent).


It's a little difficult to get the plan from that location (esp  
since the
user must choose the correct plan for the server image they want  
to use) but
I'm not convinced it is any worse than having to pull it from a  
maven repo.


It would be ideal if we could:
- Produce a single plan in the build that could work with either  
tomcat or

jetty to accompany the ear/war
- Put that plan in a more "user friendly" location (but somewhere  
under

target rather than src).
- If we do anything more, we must keep the content from polluting  
the src
tree.  Part of the work necessary to get samples to a state where  
they could
be released was to remove the special build processing that ended  
up adding
various items into the src tree which caused problems for the  
maven release

process.

Joe



David Jencks wrote:


On Oct 12, 2008, at 9:47 PM, Forrest_Xia wrote:



Generating standalone and deployment-ready war or ear ball will  
make

geronimo
samples more easier for first try, and will improve user's use
experience.

For currently generated war or ear of samples 2.1.2 release,  
user should
supply an external deployment plan.xml to make it deployable. I  
think it
will lead user bad use experience when first trying a simple  
sample war

or
ear ball.

Of course, I believe geronimo plugin is a good stuff to try those
samples,
but it takes time for user to build up geronimo plugin knowledge.

For an experienced JEE developer, he/she is used to consider  
a .ear or

.war
ball is a ready-to-deploy artifact. Suppose that, If they  
finally find

they
need to learn more about geronimo in order to make a simple  
sample's

.ear or
.war deployed succussfully, what feeling will they have?

I think well considering user's use habit and ensuring first-try  
success
experience is very important to attract new user to stay with  
our JEE

server
and consequently work with it.

So I would suggest we add back geronimo specific deployment plan  
into

packaged war or ear balls. What do you think of this?


Well, the _only_ javaee compliant location for a plan that I know  
of is
_outside_ the javaee artifact... see jsr88.  Any time you include  
a plan

inside a javaee artifact you are using a proprietary extension.

I'm not familiar with what other container recommend, are you?

Most of the samples do need a plan to indicate at least the  
dependency on
the samples datasource.  I'm not really convinced that hiding  
this pla

Re: [DISCUSS] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Joe Bohn 
NP ... when you mentioned you might be releasing saaj I just thought it 
might be a good time to try to get this cleaned up too.  Since we've 
been releasing effectively without sites (or broken sites) for some time 
now I don't think it should hinder the vote.  I just thought I'd mention 
the problem since you did include the site in the vote.


One more question:  Has any tck validation been performed for this 
updated spec?


Joe


Jarek Gawor wrote:

Doh! You did mention this issue to me before and I totally forgot. Now
I'm not sure what to do. Maybe we could release the artifacts without
the site?

Jarek

On Mon, Oct 13, 2008 at 11:19 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:

There are some issues with the maven generated site.  These aren't new
problems and they are "doc" related ... so I'm not sure if they should
really hinder the spec release.

I just started looking into them since I had some of the same problems with
the recent samples 2.1.2 release (BTW ... not all of those issues were
resolved either before we released).

- The Geronimo banner isn't included.  I think we need to make some updates
to the spec-parent site.xml (and pom.xml) and do a new release of the
specs-parent to fix this issue.  However, on my local image some of the same
changes that I made in samples to resolve this are not providing the same
magic for specs ... still looking into this.

- There are multiple links in the banner to Geronimo (on the right) and none
of them take you to the Geronimo home page.  Once again, I think this might
require some changes to the site.xml in spec-parent to fix it.

Joe

Re: Improve geronimo samples use experience

2008-10-13 Thread Lin Sun 
I agree.  It would be nice if we can provide users a downlodable
sample bundle, which contains the prebuilt artifacts and their plans.
 This would save users from learning svn, maven and digging around for
the plans.

Lin

On Mon, Oct 13, 2008 at 12:35 PM, Donald Woods <[EMAIL PROTECTED]> wrote:
> I'd like to see us generate a source + prebuilt artifacts (WAR/EAR +
> deployment plans) as a downloadable assembly off our Downloads page.
>
> Requiring users to checkout the Samples source from SVN is not friendly to
> those that don't have a svn client installed (Windows and some default Linux
> installs) and requiring them to build the Samples just so they can look at
> the deployment plans requires more work than most average users will be
> willing to spend.
>
>
> -Donald
>
>
> Joe Bohn wrote:
>>
>> I too agree that a new user should not need to deal with plugins initially
>> unless they really want to.
>>
>> I think they can already do this today ... but perhaps not as cleanly as
>> we would like (and not without the user seeing the word "plugin").
>>
>> The important thing (as David mentioned) is that they need to build the
>> samples first.  I don't think that is an unreasonable request.  In fact,
>> until our recent release of samples, a user had no choice but to build the
>> samples locally as there were no published artifacts.
>>
>> Once a user has built samples they can do the following if they don't want
>> to leverage the plugins:
>> - Install any necessary prereqs (such as the sample-datasource).  There
>> are a number of ways to do this for the datasource (if necessary) 
>> documented in the wiki.  The easiest is to install the plugin but a user
>> doesn't have to go that route. See
>> http://cwiki.apache.org/GMOxDOC21/sample-applications.html
>> - Install the specific sample artifact built locally using the archive and
>> the appropriate plan from the
>> -tomcat/target/resources/META-INF/plan.xml (or jetty equivalent).
>>
>> It's a little difficult to get the plan from that location (esp since the
>> user must choose the correct plan for the server image they want to use) but
>> I'm not convinced it is any worse than having to pull it from a maven repo.
>>
>> It would be ideal if we could:
>> - Produce a single plan in the build that could work with either tomcat or
>> jetty to accompany the ear/war
>> - Put that plan in a more "user friendly" location (but somewhere under
>> target rather than src).
>> - If we do anything more, we must keep the content from polluting the src
>> tree.  Part of the work necessary to get samples to a state where they could
>> be released was to remove the special build processing that ended up adding
>> various items into the src tree which caused problems for the maven release
>> process.
>>
>> Joe
>>
>>
>>
>> David Jencks wrote:
>>>
>>> On Oct 12, 2008, at 9:47 PM, Forrest_Xia wrote:
>>>

 Generating standalone and deployment-ready war or ear ball will make
 geronimo
 samples more easier for first try, and will improve user's use
 experience.

 For currently generated war or ear of samples 2.1.2 release, user should
 supply an external deployment plan.xml to make it deployable. I think it
 will lead user bad use experience when first trying a simple sample war
 or
 ear ball.

 Of course, I believe geronimo plugin is a good stuff to try those
 samples,
 but it takes time for user to build up geronimo plugin knowledge.

 For an experienced JEE developer, he/she is used to consider a .ear or
 .war
 ball is a ready-to-deploy artifact. Suppose that, If they finally find
 they
 need to learn more about geronimo in order to make a simple sample's
 .ear or
 .war deployed succussfully, what feeling will they have?

 I think well considering user's use habit and ensuring first-try success
 experience is very important to attract new user to stay with our JEE
 server
 and consequently work with it.

 So I would suggest we add back geronimo specific deployment plan into
 packaged war or ear balls. What do you think of this?
>>>
>>> Well, the _only_ javaee compliant location for a plan that I know of is
>>> _outside_ the javaee artifact... see jsr88.  Any time you include a plan
>>> inside a javaee artifact you are using a proprietary extension.
>>>
>>> I'm not familiar with what other container recommend, are you?
>>>
>>> Most of the samples do need a plan to indicate at least the dependency on
>>> the samples datasource.  I'm not really convinced that hiding this plan
>>> inside the javaee artifact will make it clear to users that the dependency
>>> is required.
>>>
>>> I'm not completely opposed to including a plan if we can provide some
>>> automated way to make sure it is at least as functional as the related plans
>>> in the plugin subprojects.  Do you have any ideas on how to assure this?  Is
>>> it worth the extra effort?
>>>
>>> Another pos

Re: Improve geronimo samples use experience

2008-10-13 Thread Donald Woods 
I'd like to see us generate a source + prebuilt artifacts (WAR/EAR + 
deployment plans) as a downloadable assembly off our Downloads page.


Requiring users to checkout the Samples source from SVN is not friendly 
to those that don't have a svn client installed (Windows and some 
default Linux installs) and requiring them to build the Samples just so 
they can look at the deployment plans requires more work than most 
average users will be willing to spend.



-Donald


Joe Bohn wrote:


I too agree that a new user should not need to deal with plugins 
initially unless they really want to.


I think they can already do this today ... but perhaps not as cleanly as 
we would like (and not without the user seeing the word "plugin").


The important thing (as David mentioned) is that they need to build the 
samples first.  I don't think that is an unreasonable request.  In fact, 
until our recent release of samples, a user had no choice but to build 
the samples locally as there were no published artifacts.


Once a user has built samples they can do the following if they don't 
want to leverage the plugins:
- Install any necessary prereqs (such as the sample-datasource).  There 
are a number of ways to do this for the datasource (if necessary)  
documented in the wiki.  The easiest is to install the plugin but a user 
doesn't have to go that route. See 
http://cwiki.apache.org/GMOxDOC21/sample-applications.html
- Install the specific sample artifact built locally using the archive 
and the appropriate plan from the 
-tomcat/target/resources/META-INF/plan.xml (or jetty equivalent).


It's a little difficult to get the plan from that location (esp since 
the user must choose the correct plan for the server image they want to 
use) but I'm not convinced it is any worse than having to pull it from a 
maven repo.


It would be ideal if we could:
- Produce a single plan in the build that could work with either tomcat 
or jetty to accompany the ear/war
- Put that plan in a more "user friendly" location (but somewhere under 
target rather than src).
- If we do anything more, we must keep the content from polluting the 
src tree.  Part of the work necessary to get samples to a state where 
they could be released was to remove the special build processing that 
ended up adding various items into the src tree which caused problems 
for the maven release process.


Joe



David Jencks wrote:


On Oct 12, 2008, at 9:47 PM, Forrest_Xia wrote:



Generating standalone and deployment-ready war or ear ball will make 
geronimo
samples more easier for first try, and will improve user's use 
experience.


For currently generated war or ear of samples 2.1.2 release, user should
supply an external deployment plan.xml to make it deployable. I think it
will lead user bad use experience when first trying a simple sample 
war or

ear ball.

Of course, I believe geronimo plugin is a good stuff to try those 
samples,

but it takes time for user to build up geronimo plugin knowledge.

For an experienced JEE developer, he/she is used to consider a .ear 
or .war
ball is a ready-to-deploy artifact. Suppose that, If they finally 
find they
need to learn more about geronimo in order to make a simple sample's 
.ear or

.war deployed succussfully, what feeling will they have?

I think well considering user's use habit and ensuring first-try success
experience is very important to attract new user to stay with our JEE 
server

and consequently work with it.

So I would suggest we add back geronimo specific deployment plan into
packaged war or ear balls. What do you think of this?


Well, the _only_ javaee compliant location for a plan that I know of 
is _outside_ the javaee artifact... see jsr88.  Any time you include a 
plan inside a javaee artifact you are using a proprietary extension.


I'm not familiar with what other container recommend, are you?

Most of the samples do need a plan to indicate at least the dependency 
on the samples datasource.  I'm not really convinced that hiding this 
plan inside the javaee artifact will make it clear to users that the 
dependency is required.


I'm not completely opposed to including a plan if we can provide some 
automated way to make sure it is at least as functional as the related 
plans in the plugin subprojects.  Do you have any ideas on how to 
assure this?  Is it worth the extra effort?


Another possibility might be to publish the completed plans from the 
plugin subprojects as additional attached artifacts with say 
classifier "plan".  That way the plans would be available through 
maven just as the javaee artifacts are.  To me the main problem with 
deploying the javaee artifacts is that you have to build the plugins 
anyway to get the completed plan, and making the plans as available as 
the javaee artifacts might solve this problem.


thanks
david jencks




Forrest
--
View this message in context: 
http://www.nabble.com/Improve-geronimo-samples-use-experience-tp19948784s134p19948784.ht

[jira] Commented: (GERONIMO-4354) Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar when starting Geronimo 2.1.1 on Solaris 10 x86

2008-10-13 Thread Pierre-Antoine Berreur (JIRA) 

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

Pierre-Antoine Berreur commented on GERONIMO-4354:
--

Thanks for your quick answer.

I used the .tar.gz file.
Here is my gunzip:
gunzip --version
gunzip 1.3.5
(2002-09-30)
Copyright 2002 Free Software Foundation
Copyright 1992-1993 Jean-loup Gailly
This program comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
Compilation options:
DIRENT UTIME STDC_HEADERS HAVE_UNISTD_H HAVE_MEMORY_H HAVE_STRING_H HAVE_LSTAT 
ASMV
Written by Jean-loup Gailly.
patched for Sun BugIDs 6294656 6283819
patched for CVE-2006-4334, CVE-2006-4335, CVE-2006-4336, CVE-2006-4337, 
CVE-2006-4338


For the tar I used, well I used the default one on solaris: /usr/sbin/tar. Is 
that GNU compliant ? 


For the version, well I really want to use the 2.1.1 for some testing purposes.


FYI, I've seen other people having the same problem 
(http://archive.netbsd.se/?ml=geronimo-user&a=2008-08&t=8359754), but did not 
find the cause.

> Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar 
> when starting Geronimo 2.1.1 on Solaris 10 x86
> --
>
> Key: GERONIMO-4354
> URL: https://issues.apache.org/jira/browse/GERONIMO-4354
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: installer
>Affects Versions: 2.1.1
> Environment: uname -a
> SunOS bremy 5.10 Generic_127128-06 i86pc i386 i86pc
>Reporter: Pierre-Antoine Berreur
>Priority: Blocker
>
> Can not start geronimo after unzipping it on Solaris 10.
> [EMAIL PROTECTED] /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1$ 
> ./bin/geronimo.sh run
> Using GERONIMO_BASE:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
> Using GERONIMO_HOME:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
> Using GERONIMO_TMPDIR: var/temp
> Using JRE_HOME:/usr/java/jre
> 03:23:39,177 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car"
> org.apache.geronimo.kernel.repository.MissingDependencyException: Missing 
> dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar
> at 
> org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113)
> at 
> org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:405)
> at 
> org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322)
> at 
> org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267)
> 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.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:203)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
> java.lang.IllegalStateException: GBean is not running: 
> org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.ap

Re: [DISCUSS] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Donald Woods 

Doesn't seem worth holding up the release, given the problem existed before.


-Donald


Joe Bohn wrote:
There are some issues with the maven generated site.  These aren't new 
problems and they are "doc" related ... so I'm not sure if they should 
really hinder the spec release.


I just started looking into them since I had some of the same problems 
with the recent samples 2.1.2 release (BTW ... not all of those issues 
were resolved either before we released).


- The Geronimo banner isn't included.  I think we need to make some 
updates to the spec-parent site.xml (and pom.xml) and do a new release 
of the specs-parent to fix this issue.  However, on my local image some 
of the same changes that I made in samples to resolve this are not 
providing the same magic for specs ... still looking into this.


- There are multiple links in the banner to Geronimo (on the right) and 
none of them take you to the Geronimo home page.  Once again, I think 
this might require some changes to the site.xml in spec-parent to fix it.


Joe

Re: [VOTE] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Donald Woods 

+1.  IMO, site generation problems shouldn't hold-up the release.


-Donald


Jarek Gawor wrote:

Hi,

This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one
change from version 1.0.0:

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

Staging repo:
http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/

Staging site:
http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/

The vote is open until Thursday (October 16th).

[ ] +1
[ ] +0
[ ] -1

Jarek

Re: [DISCUSS] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Jarek Gawor 
Doh! You did mention this issue to me before and I totally forgot. Now
I'm not sure what to do. Maybe we could release the artifacts without
the site?

Jarek

On Mon, Oct 13, 2008 at 11:19 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
> There are some issues with the maven generated site.  These aren't new
> problems and they are "doc" related ... so I'm not sure if they should
> really hinder the spec release.
>
> I just started looking into them since I had some of the same problems with
> the recent samples 2.1.2 release (BTW ... not all of those issues were
> resolved either before we released).
>
> - The Geronimo banner isn't included.  I think we need to make some updates
> to the spec-parent site.xml (and pom.xml) and do a new release of the
> specs-parent to fix this issue.  However, on my local image some of the same
> changes that I made in samples to resolve this are not providing the same
> magic for specs ... still looking into this.
>
> - There are multiple links in the banner to Geronimo (on the right) and none
> of them take you to the Geronimo home page.  Once again, I think this might
> require some changes to the site.xml in spec-parent to fix it.
>
> Joe
>

[jira] Commented: (GERONIMO-4354) Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar when starting Geronimo 2.1.1 on Solaris 10 x86

2008-10-13 Thread Jarek Gawor (JIRA) 

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

Jarek Gawor commented on GERONIMO-4354:
---

Did you download the zip or .tar.gz file? If you downloaded the .zip file try 
to unzip it using the "jar" tool:

jar xvf geronimo-tomcat6-javaee5-2.1.1.zip

and then you will need to mark all .sh files in 
geronimo-tomcat6-javaee5-2.1.1/bin executable:

chmod a+x geronimo-tomcat6-javaee5-2.1.1/bin/*.sh

If you downloaded the .tar.gz file make sure to use GNU tar program to unpack 
the file.

Also, I would recommend using latest Geronimo version - 2.1.3.


> Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar 
> when starting Geronimo 2.1.1 on Solaris 10 x86
> --
>
> Key: GERONIMO-4354
> URL: https://issues.apache.org/jira/browse/GERONIMO-4354
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: installer
>Affects Versions: 2.1.1
> Environment: uname -a
> SunOS bremy 5.10 Generic_127128-06 i86pc i386 i86pc
>Reporter: Pierre-Antoine Berreur
>Priority: Blocker
>
> Can not start geronimo after unzipping it on Solaris 10.
> [EMAIL PROTECTED] /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1$ 
> ./bin/geronimo.sh run
> Using GERONIMO_BASE:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
> Using GERONIMO_HOME:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
> Using GERONIMO_TMPDIR: var/temp
> Using JRE_HOME:/usr/java/jre
> 03:23:39,177 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car"
> org.apache.geronimo.kernel.repository.MissingDependencyException: Missing 
> dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar
> at 
> org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113)
> at 
> org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:405)
> at 
> org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322)
> at 
> org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267)
> 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.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:203)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
> java.lang.IllegalStateException: GBean is not running: 
> org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:205)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
> at 
> org.apache.geronimo.kernel.

[jira] Created: (GERONIMO-4354) Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar when starting Geronimo 2.1.1 on Solaris 10 x86

2008-10-13 Thread Pierre-Antoine Berreur (JIRA) 
Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar 
when starting Geronimo 2.1.1 on Solaris 10 x86
--

 Key: GERONIMO-4354
 URL: https://issues.apache.org/jira/browse/GERONIMO-4354
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: installer
Affects Versions: 2.1.1
 Environment: uname -a
SunOS bremy 5.10 Generic_127128-06 i86pc i386 i86pc

Reporter: Pierre-Antoine Berreur
Priority: Blocker


Can not start geronimo after unzipping it on Solaris 10.



[EMAIL PROTECTED] /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1$ 
./bin/geronimo.sh run
Using GERONIMO_BASE:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
Using GERONIMO_HOME:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/usr/java/jre
03:23:39,177 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
the FAILED state: 
abstractName="org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car"
org.apache.geronimo.kernel.repository.MissingDependencyException: Missing 
dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar
at 
org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113)
at 
org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:405)
at 
org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322)
at 
org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267)
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.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:203)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
java.lang.IllegalStateException: GBean is not running: 
org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car
at 
org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:205)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
[EMAIL PROTECTED] /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1$


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

[jira] Commented: (GERONIMO-4354) Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar when starting Geronimo 2.1.1 on Solaris 10 x86

2008-10-13 Thread Pierre-Antoine Berreur (JIRA) 

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

Pierre-Antoine Berreur commented on GERONIMO-4354:
--

My java version:
[EMAIL PROTECTED] /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1$ java -version
java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing)


> Missing dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar 
> when starting Geronimo 2.1.1 on Solaris 10 x86
> --
>
> Key: GERONIMO-4354
> URL: https://issues.apache.org/jira/browse/GERONIMO-4354
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: installer
>Affects Versions: 2.1.1
> Environment: uname -a
> SunOS bremy 5.10 Generic_127128-06 i86pc i386 i86pc
>Reporter: Pierre-Antoine Berreur
>Priority: Blocker
>
> Can not start geronimo after unzipping it on Solaris 10.
> [EMAIL PROTECTED] /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1$ 
> ./bin/geronimo.sh run
> Using GERONIMO_BASE:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
> Using GERONIMO_HOME:   /export/Geronimo/geronimo-tomcat6-javaee5-2.1.1
> Using GERONIMO_TMPDIR: var/temp
> Using JRE_HOME:/usr/java/jre
> 03:23:39,177 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car"
> org.apache.geronimo.kernel.repository.MissingDependencyException: Missing 
> dependency: org.apache.geronimo.framework/geronimo-common/2.1.1/jar
> at 
> org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113)
> at 
> org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:405)
> at 
> org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322)
> at 
> org.apache.geronimo.kernel.config.Configuration.(Configuration.java:267)
> 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.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:203)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
> java.lang.IllegalStateException: GBean is not running: 
> org.apache.geronimo.framework/j2ee-system/2.1.1/car?configurationName=org.apache.geronimo.framework/j2ee-system/2.1.1/car
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:205)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:167)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigu

[DISCUSS] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Joe Bohn 
There are some issues with the maven generated site.  These aren't new 
problems and they are "doc" related ... so I'm not sure if they should 
really hinder the spec release.


I just started looking into them since I had some of the same problems 
with the recent samples 2.1.2 release (BTW ... not all of those issues 
were resolved either before we released).


- The Geronimo banner isn't included.  I think we need to make some 
updates to the spec-parent site.xml (and pom.xml) and do a new release 
of the specs-parent to fix this issue.  However, on my local image some 
of the same changes that I made in samples to resolve this are not 
providing the same magic for specs ... still looking into this.


- There are multiple links in the banner to Geronimo (on the right) and 
none of them take you to the Geronimo home page.  Once again, I think 
this might require some changes to the site.xml in spec-parent to fix it.


Joe

Re: [VOTE] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Jarek Gawor 
Here's my +1.

Jarek

On Mon, Oct 13, 2008 at 10:56 AM, Jarek Gawor <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one
> change from version 1.0.0:
>
>https://issues.apache.org/jira/browse/GERONIMO-4289
>
> Staging repo:
>http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/
>
> Staging site:
>http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/
>
> The vote is open until Thursday (October 16th).
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Jarek
>

Re: [VOTE] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Davanum Srinivas 
+1

On Mon, Oct 13, 2008 at 10:56 AM, Jarek Gawor <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one
> change from version 1.0.0:
>
>https://issues.apache.org/jira/browse/GERONIMO-4289
>
> Staging repo:
>http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/
>
> Staging site:
>http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/
>
> The vote is open until Thursday (October 16th).
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Jarek
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com

[VOTE] Release SAAJ 1.3 spec jar version 1.0.1

2008-10-13 Thread Jarek Gawor 
Hi,

This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one
change from version 1.0.0:

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

Staging repo:
http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/

Staging site:
http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/

The vote is open until Thursday (October 16th).

[ ] +1
[ ] +0
[ ] -1

Jarek

Re: Improve geronimo samples use experience

2008-10-13 Thread Joe Bohn 


I too agree that a new user should not need to deal with plugins 
initially unless they really want to.


I think they can already do this today ... but perhaps not as cleanly as 
we would like (and not without the user seeing the word "plugin").


The important thing (as David mentioned) is that they need to build the 
samples first.  I don't think that is an unreasonable request.  In fact, 
until our recent release of samples, a user had no choice but to build 
the samples locally as there were no published artifacts.


Once a user has built samples they can do the following if they don't 
want to leverage the plugins:
- Install any necessary prereqs (such as the sample-datasource).  There 
are a number of ways to do this for the datasource (if necessary)  
documented in the wiki.  The easiest is to install the plugin but a user 
doesn't have to go that route. See 
http://cwiki.apache.org/GMOxDOC21/sample-applications.html
- Install the specific sample artifact built locally using the archive 
and the appropriate plan from the 
-tomcat/target/resources/META-INF/plan.xml (or jetty equivalent).


It's a little difficult to get the plan from that location (esp since 
the user must choose the correct plan for the server image they want to 
use) but I'm not convinced it is any worse than having to pull it from a 
maven repo.


It would be ideal if we could:
- Produce a single plan in the build that could work with either tomcat 
or jetty to accompany the ear/war
- Put that plan in a more "user friendly" location (but somewhere under 
target rather than src).
- If we do anything more, we must keep the content from polluting the 
src tree.  Part of the work necessary to get samples to a state where 
they could be released was to remove the special build processing that 
ended up adding various items into the src tree which caused problems 
for the maven release process.


Joe



David Jencks wrote:


On Oct 12, 2008, at 9:47 PM, Forrest_Xia wrote:



Generating standalone and deployment-ready war or ear ball will make 
geronimo
samples more easier for first try, and will improve user's use 
experience.


For currently generated war or ear of samples 2.1.2 release, user should
supply an external deployment plan.xml to make it deployable. I think it
will lead user bad use experience when first trying a simple sample 
war or

ear ball.

Of course, I believe geronimo plugin is a good stuff to try those 
samples,

but it takes time for user to build up geronimo plugin knowledge.

For an experienced JEE developer, he/she is used to consider a .ear or 
.war
ball is a ready-to-deploy artifact. Suppose that, If they finally find 
they
need to learn more about geronimo in order to make a simple sample's 
.ear or

.war deployed succussfully, what feeling will they have?

I think well considering user's use habit and ensuring first-try success
experience is very important to attract new user to stay with our JEE 
server

and consequently work with it.

So I would suggest we add back geronimo specific deployment plan into
packaged war or ear balls. What do you think of this?


Well, the _only_ javaee compliant location for a plan that I know of is 
_outside_ the javaee artifact... see jsr88.  Any time you include a plan 
inside a javaee artifact you are using a proprietary extension.


I'm not familiar with what other container recommend, are you?

Most of the samples do need a plan to indicate at least the dependency 
on the samples datasource.  I'm not really convinced that hiding this 
plan inside the javaee artifact will make it clear to users that the 
dependency is required.


I'm not completely opposed to including a plan if we can provide some 
automated way to make sure it is at least as functional as the related 
plans in the plugin subprojects.  Do you have any ideas on how to assure 
this?  Is it worth the extra effort?


Another possibility might be to publish the completed plans from the 
plugin subprojects as additional attached artifacts with say classifier 
"plan".  That way the plans would be available through maven just as the 
javaee artifacts are.  To me the main problem with deploying the javaee 
artifacts is that you have to build the plugins anyway to get the 
completed plan, and making the plans as available as the javaee 
artifacts might solve this problem.


thanks
david jencks




Forrest
--
View this message in context: 
http://www.nabble.com/Improve-geronimo-samples-use-experience-tp19948784s134p19948784.html 


Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

Re: dojo-tomcat/jetty6

2008-10-13 Thread Donald Woods 

That should have been fixed back on Oct. 9 in r703291 by Jay.



-Donald


Ivan wrote:
Just find in the newest snapshot, after I manually install the dojo 
plugin, it has an extra folder "dojo", currently when we want the refer 
to dojo.js, the url will be /dojo/dojo/dojo/dojo.js.

I suggest to repackage the dojo-mini.zip file.


2008/10/8 Lin Sun <[EMAIL PROTECTED] >

Hi Manu, Ok, making it optional sounds good.

Lin

On Wed, Oct 8, 2008 at 8:24 AM, Manu George <[EMAIL PROTECTED]
> wrote:
 > Hi Lin,
 >
 > I am using it in the EjbServer Portlet I am developing. But I guess
 > that it can also be made an optional console plugin
 >
 > Regards
 > Manu
 >
 > On Wed, Oct 8, 2008 at 1:43 AM, Lin Sun <[EMAIL PROTECTED]
> wrote:
 >> Jay,
 >>
 >> Right, I don't know how far that work went either.
 >>
 >> Thus, I didn't include the dojo-tomcat/jetty6 in the new
 >> javaee5-tomcat/jetty plugin group(profile), which will be used to
 >> build the javaee5 assemblies.
 >>
 >> Lin
 >>
 >> n Tue, Oct 7, 2008 at 3:41 PM, Jay D. McHugh
<[EMAIL PROTECTED] > wrote:
 >>> Lin,
 >>>
 >>> Someone was working on upgrading the views in Geronimo to use the
 >>> widgets in the new version of Dojo.  I don't know how far that
work went.
 >>>
 >>> So, I believe you are correct that the legacy set are the only
ones that
 >>> are currently in use.
 >>>
 >>> Jay
 >>>
 >>> Lin Sun wrote:
  I think these two portlets are using the
dojo-legacy-tomcat/jetty6.
  Nothing except the javaee5 assemblies lists dojo-tomcat/jetty6 as
  dependency.
 
  Lin
 
  On Tue, Oct 7, 2008 at 3:10 PM, Donald Woods
<[EMAIL PROTECTED] > wrote:
 > I believe only the Debug Views and Plan Creator portlets need
Dojo right
 > now, which I'm going to remove from the JEE5 assemblies and
let users
 > optionally install them, once I've updated the Welcome
portlet to include
 > some information about what optional Console plugins are
available
 >
 >
 > -Donald
 >
 >
 > Lin Sun wrote:
 >> Hi,
 >>
 >> I don't see dojo-tomcat/jetty6 is used by admin console
right now in
 >> trunk thus I plan to remove it from the javaee5 assembly.   Any
 >> objection?
 >>
 >> Whenever we have converted some of our admin console to use
 >> dojo-tomcat/jetty6, dojo-tomcat/jetty6 should be
automatically pulled
 >> into javaee5 assembly via transitive dependency, similar like
 >> dojo-legacy-tomcat/jetty6 today.
 >>
 >> Lin
 >>
 >>>
 >>
 >




--
Ivan

Re: Improved EJB integration... can we get some portlets?

2008-10-13 Thread Manu George 
Hi David,
  Thank you for the response. It was very helpful.
 Comments inline

On Fri, Oct 10, 2008 at 9:47 PM, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Oct 10, 2008, at 5:17 AM, Manu George wrote:
>
>> Hi David,
>>Thanks for replying. I have put a few questions/comments
>> inline below
>>
>> On Wed, Oct 8, 2008 at 10:09 PM, David Jencks <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Oct 8, 2008, at 7:42 AM, Manu George wrote:
>>>
>>
>>>
>>> To me it looks like you are basically proposing a plan editor or
>>> config.xml
>>> editor for openejb.  You can't safely change the actual attribute values
>>> at
>>> runtime so lets look for a solution that doesn't pretend to be able to.
>>>
>>> I think you have three possible strategies here:
>>>
>>> 1. create a plan editor for plans similar to the openejb plugin and use
>>> it
>>> to generate replacements for the openejb plugin
>>
>> Generating an entire new plugin, and installing it seems to be a lot
>> of work for the user for just changing configuration parameters. A
>> restart of the openejb configuration looks to be simpler. Another
>> factor here is that there is no mention of the MdbContainer in the
>> plan as it is generated dynamically for the RA. So such an editor
>> won't show the Mdb Container properties.
>
> I'm not sure whether to regard creating a new plugin as a significant step
> or not.  I think most of us are thinking of it as a larger bit of work than
> it is.
>
> The mdb configuration seems to be a sticky point everywhere.  I don't really
> know what is available to configure on it.  If the "knobs" you can turn are
> the same for all inbound resource adapters then perhaps we need a
> mdbtemplate gbean with named attributes for them, that provides the defaults
> for and MDBContainers we create for specific mdbs.
>
>>
.There is only 1 knob i.e instanceLimit and it is common. The Mdb
Containers are created in the openejb system gbean. So I added a
properties attribute there to store the customized values with mdb
container name as key.
>>
>>> 2. create an editor for specified customizations of config.xml.  This
>>> might
>>> or might not be practical.  It's more likely to work if the openejb
>>> plugin
>>> is stopped when you edit gbean attribute values.
>>
>> If I do stop the openejb configuration then would I be able to edit
>> the gbean attributes? After all they are final and would have already
>> been intialized.  I am assuming that even before a gbean is started
>> its constructor is called. (GBean Loading Stage).
>> Another issue here is since the portlet should depend on the openejb
>> configuration it will also get stopped and removed from the admin
>> console if I stop the openejb configuration.
>>
>> I am unable to change the attributes of the gbean at runtime as all
>> the fields are final and there are no setter methods. However if I
>> have setter methods then i would be able to set the attributes at
>> runtime to the gbean. However the ejb containers will need to be
>> reinitialized which needs a restart of the openejb container system.
>> We can prompt the user to restart the openejb configuration.
>
> Stopping a gbean discards the gbean object instance.  You're left with the
> GBeanData which is basically a map holding attribute values.  This you can
> definitely edit.
>
> Any kind of configuration facility like this would not require the openjeb
> plugin to be started, just loaded.  You can specify a
> classes dependency on openejb to get this, just like the
> openejb-deployer plugin does.  This would let you cycle the openejb plugin
> while the console is running.  (Obviously this won't work for a jetty/tomcat
> console plugin :-)
>
I am writing a jetty/tomcat plugin. I will externalize the
configurable properties to config-substitutions.properties.
However on editing I plan to edit the config.xml. The reason for this
is that later I plan to add the ability to create containers
dynamically and to configure them using the console. This will be
useful if u want some stateless beans to have say a different pool
size than others and so forth. In that case i would need to generate
keys for config-substitution.properties for each new container. So I
am planning on directly editing the config.xml in which case its not
required to have any configuration info in the plugin as u mentioned

>>
>>
>>> 3. put all the things you want to be able to change into
>>> config-substitutions as variables and edit those (in the in-memory map
>>> accessible through () ArtifactResolver).
>>
>> This sounds interesting. How can I access this inMemoryMap (not yet
>> figured out) and will the changes to the Map be persisted to the
>> config.xml file or the config-substitutions.properties file? If not
>> the changes will be lost on server shutdown.
>
> The method is
> org.apache.geronimo.system.configuration.PluginAttributeStore.addConfigSubstitutions(Properties
> properties) which is implemented in LocalAttributeManag

[jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up

2008-10-13 Thread ant elder (JIRA) 

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

ant elder commented on GERONIMO-4343:
-

Turns out there are some issues with that add-jms-sca-binding.diff patch which 
i'll need to fix in Tuscany before the plugin can use it, so could that patch 
be reverted for now?

> Tuscany Geronimo plugin bring up
> 
>
> Key: GERONIMO-4343
> URL: https://issues.apache.org/jira/browse/GERONIMO-4343
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: ant elder
> Attachments: add-jms-sca-binding.diff, asm.diff, 
> GeronimoServletHost1.diff, GeronimoServletHost2.diff, tuscany-core-1.3.jar, 
> tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, 
> wsdlgen-depenency.diff
>
>
> JIRA to cover getting the Tuscany Geronimo Plugin working again with the 
> latest releases of Tuscany and Geronimo. 

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

[jira] Updated: (GERONIMO-4352) IMAP provider: accessing parts of a multipart/mixed message causes invalid command

2008-10-13 Thread Rick McGuire (JIRA) 

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

Rick McGuire updated GERONIMO-4352:
---

Attachment: GERONIMO-4352.diff

Andreas, the attached patch passes the tests I've managed to run.  Could you 
verify that this is working correctly on your server environment before I 
commit it?

> IMAP provider: accessing parts of a multipart/mixed message causes invalid 
> command
> --
>
> Key: GERONIMO-4352
> URL: https://issues.apache.org/jira/browse/GERONIMO-4352
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Andreas Veithen
>Assignee: Rick McGuire
> Attachments: 03-javamail.log, GERONIMO-4352.diff
>
>
> When accessing the content of the second part of a multipart/mixed message 
> (see attachment), the following IMAP command is sent:
> FETCH 1 (BODY.PEEK[2.TEXT])
> This results in an error (FETCH failed). IMAP server is GreenMail: 
> http://www.icegreen.com/greenmail/
> RFC3501 says about the TEXT part specifier:
>  The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
>  specifiers can be the sole part specifier or can be prefixed by
>  one or more numeric part specifiers, provided that the numeric
>  part specifier refers to a part of type MESSAGE/RFC822.  The
>  MIME part specifier MUST be prefixed by one or more numeric
>  part specifiers.
> Since the second part is not message/rfc822, the command issued is incorrect. 
> I believe that the correct command in this case should be:
> FETCH 1 (BODY.PEEK[2])

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

[jira] Assigned: (GERONIMO-4352) IMAP provider: accessing parts of a multipart/mixed message causes invalid command

2008-10-13 Thread Rick McGuire (JIRA) 

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

Rick McGuire reassigned GERONIMO-4352:
--

Assignee: Rick McGuire

> IMAP provider: accessing parts of a multipart/mixed message causes invalid 
> command
> --
>
> Key: GERONIMO-4352
> URL: https://issues.apache.org/jira/browse/GERONIMO-4352
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Andreas Veithen
>Assignee: Rick McGuire
> Attachments: 03-javamail.log
>
>
> When accessing the content of the second part of a multipart/mixed message 
> (see attachment), the following IMAP command is sent:
> FETCH 1 (BODY.PEEK[2.TEXT])
> This results in an error (FETCH failed). IMAP server is GreenMail: 
> http://www.icegreen.com/greenmail/
> RFC3501 says about the TEXT part specifier:
>  The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
>  specifiers can be the sole part specifier or can be prefixed by
>  one or more numeric part specifiers, provided that the numeric
>  part specifier refers to a part of type MESSAGE/RFC822.  The
>  MIME part specifier MUST be prefixed by one or more numeric
>  part specifiers.
> Since the second part is not message/rfc822, the command issued is incorrect. 
> I believe that the correct command in this case should be:
> FETCH 1 (BODY.PEEK[2])

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

[BUILD] trunk: Failed for Revision: 703929

2008-10-13 Thread gawor 
Geronimo Revision: 703929 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081013/build-0300.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081013/unit-test-reports
 
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/genesis/config/project-config/1.5-SNAPSHOT/project-config-1.5-SNAPSHOT.pom
16K downloaded
[INFO] snapshot org.apache.geronimo.genesis.config:config:1.5-SNAPSHOT: 
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.genesis.config:config:1.5-SNAPSHOT: 
checking for updates from codehaus-snapshots
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/genesis/config/config/1.5-SNAPSHOT/config-1.5-SNAPSHOT.pom
2K downloaded
[INFO] snapshot org.apache.geronimo.genesis:genesis:1.5-SNAPSHOT: checking for 
updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.genesis:genesis:1.5-SNAPSHOT: checking for 
updates from codehaus-snapshots
Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/genesis/genesis/1.5-SNAPSHOT/genesis-1.5-SNAPSHOT.pom
13K downloaded
Downloading: http://download.java.net/maven/1//org.apache/poms/apache-4.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//org/apache/apache/4/apache-4.pom
Downloading: http://repo1.maven.org/maven2/org/apache/apache/4/apache-4.pom
4K downloaded
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Failed to resolve artifact.

GroupId: org.apache
ArtifactId: apache
Version: 4

Reason: Unable to download the artifact from any repository

  org.apache:apache:pom:4

from the specified remote repositories:
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  java.net (http://download.java.net/maven/1/),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/),
  ibiblio.org (http://repo1.maven.org/maven2)


[INFO] 
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent: 
org.apache:apache for project: 
org.apache.geronimo.genesis:genesis:pom:1.5-SNAPSHOT for project 
org.apache.geronimo.genesis:genesis:pom:1.5-SNAPSHOT
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find 
parent: org.apache:apache for project: 
org.apache.geronimo.genesis:genesis:pom:1.5-SNAPSHOT for project 
org.apache.geronimo.genesis:genesis:pom:1.5-SNAPSHOT
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1387)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1387)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1387)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM 
'org.apache:apache' not found in repository: Unable to download the artifact 
from any repository

  org.apache:apache:pom:4

from the specified remote re