Re: SVN Branches

[Geir Magnusson Jr]

On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote:
It is covered in the subversion book http://svnbook.red-bean.com/
Can understand why you would want to branch for security, but I think 
you should keep working on your deployment stuff in the main trunk.
If it's easy to fold back in, why not do in a branch?  There's clearly 
a difference of opinion here, one in which both sides feel pretty 
strongly.  Out of respect and courtesy, why not do in a branch if the 
downside costs of having to bring it back to trunk are so low?

It's rather traditional in some other projects I've been in to 
demonstrate contrary ideas in a way that guarantees good exposure to 
the community, with little disruption.

geir
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Nov 4, 2004, at 3:11 PM, Aaron Mulder wrote:
Is there a way to branch a few files or directories and leave the
rest of the server tracking with the trunk?
	For example, if I wanted to branch security or deployment, in such
a way that you could check out my branch and get the most current 
versions
of everything, except my versions of security or deployment.

	The best I've heard is to branch everything, apply my changes, and
then continually merge changes from trunk to branch.  This has 2 
problems:

1) I have to keep track of the last trunk rev I merged to the branch 
so
that next time I can only merge from that point to the current rev

2) I have to resolve conflicts in my branched code, if there were any
trunk changes to that
Thanks,
Aaron

--
Geir Magnusson Jr  +1-203-665-6437
[EMAIL PROTECTED]

Re: SVN Branches

[Dain Sundstrom]

It is covered in the subversion book http://svnbook.red-bean.com/
Can understand why you would want to branch for security, but I think 
you should keep working on your deployment stuff in the main trunk.

-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Nov 4, 2004, at 3:11 PM, Aaron Mulder wrote:
Is there a way to branch a few files or directories and leave the
rest of the server tracking with the trunk?
	For example, if I wanted to branch security or deployment, in such
a way that you could check out my branch and get the most current 
versions
of everything, except my versions of security or deployment.

	The best I've heard is to branch everything, apply my changes, and
then continually merge changes from trunk to branch.  This has 2 
problems:

1) I have to keep track of the last trunk rev I merged to the branch so
that next time I can only merge from that point to the current rev
2) I have to resolve conflicts in my branched code, if there were any
trunk changes to that
Thanks,
Aaron

Re: Deployment Status

[Dain Sundstrom]

On Nov 4, 2004, at 3:07 PM, Aaron Mulder wrote:
I talked to Jeremy.  Our plan for now is that I will check in a
deployer tool that includes the following features:
 - everything, when working online (on the same PC as the server)
 - package and distribute, when working offline (on the same PC)
 - nothing, when working online (on a different PC from the server)
This is basically the same functionality in the current
deployer.jar tool, plus online same-PC deployment via JSR-88.
So in your off list discussion what features got axed?
	Jeremy is going to write up a "position paper" regarding
additional offline deployer features when he gets a chance (next 
couple of
days?).  He has concerns about the original vision of a single unified
offline+online tool.  (We should spend some time on this at the 
Hackathon
if it's not resolved sooner.)
That doesn't sound like the Apache way to me.  This plan was discussed 
on the list and the community came to a decision.  I think you should 
continue your development and Jeremy can complain when he gets time.

-dain

SVN Branches

[Aaron Mulder]

Is there a way to branch a few files or directories and leave the 
rest of the server tracking with the trunk?

For example, if I wanted to branch security or deployment, in such 
a way that you could check out my branch and get the most current versions 
of everything, except my versions of security or deployment.

The best I've heard is to branch everything, apply my changes, and 
then continually merge changes from trunk to branch.  This has 2 problems:

1) I have to keep track of the last trunk rev I merged to the branch so 
that next time I can only merge from that point to the current rev

2) I have to resolve conflicts in my branched code, if there were any 
trunk changes to that

Thanks,
Aaron

Deployment Status

[Aaron Mulder]

I talked to Jeremy.  Our plan for now is that I will check in a 
deployer tool that includes the following features:

 - everything, when working online (on the same PC as the server)
 - package and distribute, when working offline (on the same PC)
 - nothing, when working online (on a different PC from the server)

This is basically the same functionality in the current 
deployer.jar tool, plus online same-PC deployment via JSR-88.

Jeremy is going to write up a "position paper" regarding 
additional offline deployer features when he gets a chance (next couple of 
days?).  He has concerns about the original vision of a single unified 
offline+online tool.  (We should spend some time on this at the Hackathon 
if it's not resolved sooner.)

Jeremy is also working on the remote-PC JSR-88 implementation, and 
the tool will be updated to work with that once it's ready.

Aaron

[jira] Commented: (GERONIMO-408) TM and active mark: Testing Build fails with InvalidConfigException caused by: org.objectweb.howl.log.LogClosedException

[toby cabot (JIRA)]

 [ 
http://nagoya.apache.org/jira/browse/GERONIMO-408?page=comments#action_55063 ]
 
toby cabot commented on GERONIMO-408:
-

Yup, Ralf's correct, it looks like GERONIMO-437 is a dupe of this bug.  The 
only data I'd move over from that bug to this one is that if I copy 
howl-logger-0.1.7.jar over howl-logger-0.1.7-SNAPSHOT.jar (in the maven 
repository) then things work fine.


> TM and active mark: Testing Build fails with InvalidConfigException caused 
> by: org.objectweb.howl.log.LogClosedException
> 
>
>  Key: GERONIMO-408
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-408
>  Project: Apache Geronimo
> Type: Bug
>   Components: buildsystem, transaction manager
> Versions: 1.0-M3
>  Environment: Maven v. 1.0
> java version "1.4.2_05"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
> Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)
> Microsoft Windows 2000 [Version 5.00.2195]
> Reporter: Ralf Barkow
> Priority: Blocker
>  Attachments: geronimo-DebugConsole.log, 
> geronimo-transaction_test-reports_errors.zip, geronimo.log.zip
>
> Does the TM set an active mark?  
> Testing the current build with
> $ java -jar modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/server.jar 
> org/apache/geronimo/DebugConsole
> (...)
> fails (see attachted log files).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-431) ServerInfo saves a guessed Geronimo Home

[Dain Sundstrom (JIRA)]

 [ http://nagoya.apache.org/jira/browse/GERONIMO-431?page=history ]
 
Dain Sundstrom closed GERONIMO-431:
---

Resolution: Fixed

The getBaseDirectory method no longer returns the guessed based directory.  Now 
the only way to interact with the real base directory is via on  of the resolve 
methods.

> ServerInfo saves a guessed Geronimo Home
> 
>
>  Key: GERONIMO-431
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-431
>  Project: Apache Geronimo
> Type: Bug
>   Components: kernel
> Reporter: Dain Sundstrom
> Assignee: Dain Sundstrom

>
> When server info is persisted it saves out the guessed path to Geronimo home. 
>  This means that once the server is run it can not be moved to a new 
> location.  This is particularly bad because in the assembly module we start 
> the server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Dain Sundstrom]

My gut feeling is that would be more trouble then it is worth.  The 
project still must build the tree every day, so we know that the source 
is consistent.  Also, before someone commits code they must build the 
whole tree to make sure they didn't introduce a subtle bug.

-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Nov 4, 2004, at 1:29 PM, Davanum Srinivas wrote:
ok
On Thu, 04 Nov 2004 15:11:17  -, David Farb 
<[EMAIL PROTECTED]> wrote:
Axis may be required for J2EE 1.4 compliance, but I don't think that
necessarily translates into one very large build containing every
component.
If someone is working on the Axis integration, then why should they be
held up because of a problem with the integration of some other 
module.

If the build were subdivided into some fundamental modules (kernel,
core, system, naming, network, ...) which could be built and assembled
as a unit, and then other modules or groups of modules built on top of
that core, (Say a Jetty-Axis web group ...), it would then be possible
to build just the parts you really want.
This makes work on some particular part of Geronimo easier since that
work is dependent ONLY on the code it really needs.


--
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Dain Sundstrom]

On Nov 4, 2004, at 12:52 PM, Jeremy Boynes wrote:
Aaron Mulder wrote:
	For what it's worth, I can't recall having a problem with Tomcat,
JBoss or WebLogic where it processed a partially copied file or had a 
race
condition or was unable to revert or it was unclear to me whether the
application was successfully deployed (either you get big stack 
traces or
you don't).  So I think we can solve those problems.
I have seen that many times. The obvious use case is when you are 
doing testing where you end up doing something like:

  copy file to directory
  run tests
and the app has not finished deploying yet. So then you add a couple 
of "sleep for a bit" but when you are running a couple hundred tests 
that gets to be boring.
So... people do all sorts of stupid stuff, and we can't stop them.  I 
don't think we should restrict a feature just because some people use 
is incorrectly.

	More importantly, the first time any J2EE developer sits down
with a new server, I bet they try to deploy some app they have sitting
around, and I bet they try to do it by dumping it in the deploy 
directory.  Now we can teach them to use a tool instead, but I think 
in rejecting a
hot deploy directory you're introducing a hurdle to adoption (must 
consult
doucmentation and learn tool syntax and set up tool execution 
environment)
because you don't like the standard process.
"standard process" - wouldn't that be JSR-88?
There's nothing to stop anyone doing this - just write a GBean that 
acts as a directory scanner and invokes the online deployer. If they 
wanted to be fancy, they could have ones that scanned websites using 
WebDAV or offered some basic security.
You lost me... you seem to be arguing against adding this feature, but 
then you say that "there's nothing to stop anyone doing this".  So it 
is possible, but you don't want Geronimo to provide this?

-dain

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Davanum Srinivas]

ok


On Thu, 04 Nov 2004 15:11:17  -, David Farb <[EMAIL PROTECTED]> wrote:
> 
> Axis may be required for J2EE 1.4 compliance, but I don't think that
> necessarily translates into one very large build containing every
> component.
> 
> If someone is working on the Axis integration, then why should they be
> held up because of a problem with the integration of some other module.
> 
> If the build were subdivided into some fundamental modules (kernel,
> core, system, naming, network, ...) which could be built and assembled
> as a unit, and then other modules or groups of modules built on top of
> that core, (Say a Jetty-Axis web group ...), it would then be possible
> to build just the parts you really want.
> 
> This makes work on some particular part of Geronimo easier since that
> work is dependent ONLY on the code it really needs.
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[David Farb]

Axis may be required for J2EE 1.4 compliance, but I don't think that 
necessarily translates into one very large build containing every 
component. 

If someone is working on the Axis integration, then why should they be 
held up because of a problem with the integration of some other module.

If the build were subdivided into some fundamental modules (kernel, 
core, system, naming, network, ...) which could be built and assembled 
as a unit, and then other modules or groups of modules built on top of 
that core, (Say a Jetty-Axis web group ...), it would then be possible 
to build just the parts you really want. 

This makes work on some particular part of Geronimo easier since that 
work is dependent ONLY on the code it really needs.

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Jeremy Boynes]

Aaron Mulder wrote:
For what it's worth, I can't recall having a problem with Tomcat,
JBoss or WebLogic where it processed a partially copied file or had a race
condition or was unable to revert or it was unclear to me whether the
application was successfully deployed (either you get big stack traces or
you don't).  So I think we can solve those problems.
I have seen that many times. The obvious use case is when you are doing 
testing where you end up doing something like:

  copy file to directory
  run tests
and the app has not finished deploying yet. So then you add a couple of 
"sleep for a bit" but when you are running a couple hundred tests that 
gets to be boring.

	More importantly, the first time any J2EE developer sits down
with a new server, I bet they try to deploy some app they have sitting
around, and I bet they try to do it by dumping it in the deploy directory.  
Now we can teach them to use a tool instead, but I think in rejecting a
hot deploy directory you're introducing a hurdle to adoption (must consult
doucmentation and learn tool syntax and set up tool execution environment)
because you don't like the standard process.

"standard process" - wouldn't that be JSR-88?
There's nothing to stop anyone doing this - just write a GBean that acts 
as a directory scanner and invokes the online deployer. If they wanted 
to be fancy, they could have ones that scanned websites using WebDAV or 
offered some basic security.

I think having good tools is useful and I appreciate the work you are 
doing on the deployer. I'm not trying to be difficult or over "correct", 
just trying to ensure that we don't repeat the mistakes of the past, at 
least without thinking about them. Reminds me of the post on Slashdot 
yesterday about problems with Virtual Worlds.

http://www.gamasutra.com/features/20041103/bartle_pfv.htm
--
Jeremy

Re: [jira] Created: (GERONIMO-437) test/runtime failures with latest HOWL logger

[Ralf Barkow]

   Looks like to be the same issue as 
http://nagoya.apache.org/jira/browse/GERONIMO-408

--  Ralf

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Davanum Srinivas]

About Axis, J2EE 1.4 mandates several web services jsr's and we have
to make it work seemlessly with the rest of the system. I apologize
for the geronimo-axis module breaking builds. If Axis breaks i will
fix it ASAP or comment it out myself in the project.properties.

thanks,
dims


On Thu, 04 Nov 2004 17:06:32 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>Date: 2004-11-04T09:06:32
>Editor: DavidFarb <[EMAIL PROTECTED]>
>Wiki: Apache Geronimo Wiki
>Page: WishList/M3
>URL: http://wiki.apache.org/geronimo/WishList/M3
> 
>no comment
> 
> Change Log:
> 
> --
> @@ -28,3 +28,9 @@
>  = Hot Deploy Dir =
> 
>  Would be nice to have "dump EAR here, it gets (re)deployed" directory
> +
> += Stable Nightly Buildable Source =
> +
> +Would be nice if the nightly extraction from Subversion usually built.
> +Along those lines, why not break Geronimo into a core set of modules and an 
> optional set.
> +For example, if some one is not using Derby, Axis or Spring, why should 
> thier nightly build be dependant on them?
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: How to updated config.list during offline deployment

[Aaron Mulder]

On Thu, 4 Nov 2004, Jeremy Boynes wrote:
> No, you were proposing having the deployment tool hack the internal file 
> used by a specific GBean. I object to that as it relies on 
> implementation detail.

Hmm.  Obviously we're not on the same page here.

So you would be totally comfortable with this if we use the GBean 
to access the file, rather than writing to it directly?

> > You seem to be sugesting that the deploy tool should only work fully
> > when the server is running, and if the server is not running, then you
> > need to use a different command to start the server and deploy at the
> > same time.  Is that right?
>
> No, I was proposing adding the command line option to the server that 
> added a configId to the list retrieved from the last-known-configs 
> GBean. This is a portable way of achieving what you were trying to do 
> above. It is also simply "start" and not "deploy"

Is this your position:

 - the deploy tool should not support "start" when the server is not 
running (but it's fine to support it when the server is running)

 - the server should offer a command line argument that gets you the 
"start" functionality

If so, I would claim this uses two tools (deployer.jar, 
server.jar) and also makes the deployer behave differently depending on 
whether the server is running (start works, start doesn't work).

Also, how is the server.jar option you're proposing different than 
the existing option to just pass a configId on the command line?  What 
does the new option do that the old one doesn't?

Thanks,
Aaron

[jira] Commented: (GERONIMO-437) test/runtime failures with latest HOWL logger

[toby cabot (JIRA)]

 [ 
http://nagoya.apache.org/jira/browse/GERONIMO-437?page=comments#action_55059 ]
 
toby cabot commented on GERONIMO-437:
-

forgot to mention: if I run the build so that it doesn't run the unit tests 
then it succeeds but I get a similar stack trace when I start the server.


> test/runtime failures with latest HOWL logger
> -
>
>  Key: GERONIMO-437
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-437
>  Project: Apache Geronimo
> Type: Bug
>   Components: transaction manager
> Versions: 1.0-M2
>  Environment: java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
> fedora core 2 and red hat 9
> Reporter: toby cabot

>
> I get build-time unit test failures with the latest version of 
> ~/.maven/repository/howl/jars/howl-logger-0.1.7-SNAPSHOT.jar.  If I copy 
> howl-logger-0.1.7.jar over howl-logger-0.1.7-SNAPSHOT.jar then things work 
> fine.
> build output is:
> test:test:
> [junit] Running org.apache.geronimo.transaction.log.HOWLLogTest
> [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.225 sec
> [junit] [ERROR] TEST org.apache.geronimo.transaction.log.HOWLLogTest 
> FAILED
> [junit] Running 
> org.apache.geronimo.transaction.context.TransactionContextManagerTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.21 sec
> [junit] Running org.apache.geronimo.transaction.manager.ProtocolTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.084 sec
> [junit] Running org.apache.geronimo.transaction.manager.XidImporterTest
> [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.052 sec
> [junit] Running 
> org.apache.geronimo.transaction.manager.MockLogRecoveryTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.142 sec
> [junit] Running 
> org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest
> [junit] Tests run: 5, Failures: 0, Errors: 5, Time elapsed: 0.153 sec
> [junit] [ERROR] TEST 
> org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest FAILED
> [junit] Running org.apache.geronimo.transaction.manager.RecoveryTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.046 sec
> [junit] Running 
> org.apache.geronimo.transaction.TransactionManagerProxyTest
> [junit] Tests run: 13, Failures: 0, Errors: 0, Time elapsed: 0.052 sec
>  
> the contents of TEST-org.apache.geronimo.transaction.log.HOWLLogTest.txt are:
> Testcase: 
> testTransactionLog(org.apache.geronimo.transaction.log.HOWLLogTest):
> Caused an ERROR
> org.objectweb.howl.log.InvalidLogKeyException: The initial mark [0] requested 
> for replay was not found in the log.
> org.objectweb.howl.log.LogClosedException: 
> org.objectweb.howl.log.InvalidLogKeyException: The initial mark [0] requested 
> for replay was not found in the log.
>   at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:858)
>   at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:217)
>   at 
> org.apache.geronimo.transaction.log.HOWLLogTest.createTransactionLog(HOWLLogTest.java:67)
>   at 
> org.apache.geronimo.transaction.log.AbstractLogTest.testTransactionLog(AbstractLogTest.java:92)
>   at 
> org.apache.geronimo.transaction.log.AbstractLogTest.testTransactionLog(AbstractLogTest.java:70)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>   at junit.extensions.TestSetup.run(TestSetup.java:23)
>   at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>   at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
>   at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>   at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>   at 
> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>   at com.werken.werkz.Goal.fire(Goal.java:639)
>   at com.werken.werkz.Goal.attain(Goal.java:575)
>   at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>   at com.werken.werkz.Goal.attain(Goal.java:573)
>   at com.werken.werkz.Goal.attainPrecursors

Undeliverable mail: [jira] Created: (GERONIMO-436) JSR-88: Targets Ignored

[MAILER-DAEMON]

Failed to deliver to '[EMAIL PROTECTED]'
SMTP module(domain geronimo.apache.org) reports:
 host mail.apache.org says:
 550 SPF forgery: Please see 
http://spf.pobox.com/why.html?sender=dev%40geronimo.apache.org&ip=63.247.192.101&receiver=hermes.apache.org

Reporting-MTA: dns; mailsvc.com

Original-Recipient: rfc822;
Final-Recipient: rfc822;
Action: failed
Status: 5.0.0
Received: by mailsvc.com (CommuniGate Pro PIPE 4.2)
  with PIPE id 101270098; Thu, 04 Nov 2004 13:28:48 -0700
Received: from mail.apache.org ([209.237.227.199] verified)
  by mailsvc.com (CommuniGate Pro SMTP 4.2)
  with SMTP id 101270056 for [EMAIL PROTECTED]; Thu, 04 Nov 2004 13:28:40 -0700
Received: (qmail 10482 invoked by uid 500); 4 Nov 2004 20:28:35 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
list-help: 
list-unsubscribe: 
list-post: 
Reply-To: [EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 10467 invoked by uid 99); 4 Nov 2004 20:28:35 -
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10)
  by apache.org (qpsmtpd/0.28) with SMTP; Thu, 04 Nov 2004 12:28:33 -0800
Received: (qmail 9338 invoked from network); 4 Nov 2004 20:28:32 -
Received: from localhost (HELO nagoya) (127.0.0.1)
  by nagoya.betaversion.org with SMTP; 4 Nov 2004 20:28:32 -
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 4 Nov 2004 12:28:32 -0800 (PST)
From: "Aaron Mulder (JIRA)" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [jira] Created: (GERONIMO-436) JSR-88: Targets Ignored
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-CIT-MailScanner-Information: Please contact 719-473-2800 for more information
X-CIT-MailScanner-IA: Not scanned for viruses: Contact Colorado Information Technologies at 1-866-469-3310 to add Virus and Spam filtering services
X-CIT-MailScanner-SpamCheck: 
X-MailScanner-From: [EMAIL PROTECTED]

[jira] Created: (GERONIMO-437) test/runtime failures with latest HOWL logger

[toby cabot (JIRA)]

test/runtime failures with latest HOWL logger
-

 Key: GERONIMO-437
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-437
 Project: Apache Geronimo
Type: Bug
  Components: transaction manager  
Versions: 1.0-M2
 Environment: java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
fedora core 2 and red hat 9

Reporter: toby cabot


I get build-time unit test failures with the latest version of 
~/.maven/repository/howl/jars/howl-logger-0.1.7-SNAPSHOT.jar.  If I copy 
howl-logger-0.1.7.jar over howl-logger-0.1.7-SNAPSHOT.jar then things work fine.

build output is:

test:test:
[junit] Running org.apache.geronimo.transaction.log.HOWLLogTest
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.225 sec
[junit] [ERROR] TEST org.apache.geronimo.transaction.log.HOWLLogTest FAILED
[junit] Running 
org.apache.geronimo.transaction.context.TransactionContextManagerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.21 sec
[junit] Running org.apache.geronimo.transaction.manager.ProtocolTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.084 sec
[junit] Running org.apache.geronimo.transaction.manager.XidImporterTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.052 sec
[junit] Running org.apache.geronimo.transaction.manager.MockLogRecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.142 sec
[junit] Running org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest
[junit] Tests run: 5, Failures: 0, Errors: 5, Time elapsed: 0.153 sec
[junit] [ERROR] TEST 
org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest FAILED
[junit] Running org.apache.geronimo.transaction.manager.RecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.046 sec
[junit] Running org.apache.geronimo.transaction.TransactionManagerProxyTest
[junit] Tests run: 13, Failures: 0, Errors: 0, Time elapsed: 0.052 sec
 
the contents of TEST-org.apache.geronimo.transaction.log.HOWLLogTest.txt are:

Testcase: testTransactionLog(org.apache.geronimo.transaction.log.HOWLLogTest):  
Caused an ERROR
org.objectweb.howl.log.InvalidLogKeyException: The initial mark [0] requested 
for replay was not found in the log.
org.objectweb.howl.log.LogClosedException: 
org.objectweb.howl.log.InvalidLogKeyException: The initial mark [0] requested 
for replay was not found in the log.
at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:858)
at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:217)
at 
org.apache.geronimo.transaction.log.HOWLLogTest.createTransactionLog(HOWLLogTest.java:67)
at 
org.apache.geronimo.transaction.log.AbstractLogTest.testTransactionLog(AbstractLogTest.java:92)
at 
org.apache.geronimo.transaction.log.AbstractLogTest.testTransactionLog(AbstractLogTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at 
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at 
org.apache.maven.jelly.tags.werkz.M

[jira] Updated: (GERONIMO-264) exceptions being swallowed at startup

[toby cabot (JIRA)]

 [ http://nagoya.apache.org/jira/browse/GERONIMO-264?page=history ]

toby cabot updated GERONIMO-264:


Attachment: Daemon-56609-diff.txt

here's an updated patch which merges with version 56609 of Daemon.java.  While 
this is a trivial change in terms of code, it makes a big difference in 
usability, especially for new users.  Without the patch, exceptions appear out 
of order which makes it harder to see what caused what.  I think that this 
would be a worthwhile improvement for M3.

> exceptions being swallowed at startup
> -
>
>  Key: GERONIMO-264
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-264
>  Project: Apache Geronimo
> Type: Improvement
>   Components: deployment
> Versions: 1.0-M2
>  Environment: fedora core 2
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> Reporter: toby cabot
> Assignee: Dain Sundstrom
> Priority: Minor
>  Attachments: Daemon-1_9-diff.txt, Daemon-56609-diff.txt, daemon-log.diff, 
> daemon-log.diff, log.txt
>
> some exceptions that are thrown during startup are swallowed and don't show 
> up in the logs.
> i'm at the 'monkey and typewriter' stage of the geronimo learning curve so 
> i'm a good randomness injector.  i had a problem where geronimo would try to 
> start up and then go directly to shutdown for no apparent reason.  actually, 
> i think i've had a few:
> 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name="skeleton/RA" State 
> changed from stopped to starting
> 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to 
> [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar]
> ra test setting configParameter to NewStringValue
> 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] 
> BaseManagedConnectionFactory()
> 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] 
> SpreadManagedConnectionFactory()
> 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name="skeleton/RA" State 
> changed from starting to failed
> 15:50:18,426 INFO  [Kernel] Starting kernel shutdown
> i'll include a patch that logs the problem in the catch clause in 
> Configuration.doStart().  There might be better places to do this, but as 
> long as it gets done *somewhere* i'm happy.
> regards,
> toby

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Re: Calling all Early(?) adopters

[Davanum Srinivas]

sorryM4 it is.

-- dims


On Thu, 4 Nov 2004 11:55:51 -0800, David Blevins <[EMAIL PROTECTED]> wrote:
> Don't you mean M4?  We just voted to release M3 now.
> 
> -David
> 
> 
> 
> On Nov 4, 2004, at 8:49 AM, Davanum Srinivas wrote:
> 
> > Dear Early Adopters,
> >
> > If you have tried Geronimo already (or in the process of doing so),
> > please let us know how we can make it easier Out-Of-The-Box for
> > everyone...Here are some things we jotted down to get the ball
> > rolling:
> > http://wiki.apache.org/geronimo/WishList/M3
> >
> > thanks,
> > dims
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: How to updated config.list during offline deployment

[Jeremy Boynes]

Aaron Mulder wrote:
	What I am proposing is the equivalent of using the current deploy 
tool, and then adding the module's configId to the server command line 
next time you start it -- which is what you can do today.  I don't see how 
that makes the situation worse.

No, you were proposing having the deployment tool hack the internal file 
used by a specific GBean. I object to that as it relies on 
implementation detail.

You seem to be sugesting that the deploy tool should only work
fully when the server is running, and if the server is not running, then
you need to use a different command to start the server and deploy at the
same time.  Is that right?
No, I was proposing adding the command line option to the server that 
added a configId to the list retrieved from the last-known-configs 
GBean. This is a portable way of achieving what you were trying to do 
above. It is also simply "start" and not "deploy"

You can install(distribute) offline to your heart's content but I don't 
want the user fooled into thinking their app is startable when it isn't. 
The "deploy" tool (as in distribute/start) can *only* work with a 
running server as that is the only way to tell if the application is 
startable.

I think the typical usage will be:
start server
repeat
   write code
   build (with distribute/start to online server)
   test
until app works or it's time to go home
rather than
repeat
  write code
  build (with 'deploy' to offline server)
  start server
  check logs for errors
  test
  stop server
until app works or it's time to go home
We should make the first simple and reliable.
--
Jeremy

[jira] Created: (GERONIMO-436) JSR-88: Targets Ignored

[Aaron Mulder (JIRA)]

JSR-88: Targets Ignored
---

 Key: GERONIMO-436
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-436
 Project: Apache Geronimo
Type: Bug
  Components: deployment  
Versions: 1.0-M2
Reporter: Aaron Mulder


The current JSR-88 deployer (JMXDeploymentManager) may potentially provide a 
list of targets for getTargets() -- one per config store.

However, all the methods that take an array of Target or TargetModuleID objects 
ignore the specified Targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Aaron Mulder]

On Thu, 4 Nov 2004 [EMAIL PROTECTED] wrote:
>  Would be nice to have "dump EAR here, it gets (re)deployed" directory
>  
> +[jboynes] I really, really don't like this option. With the right
> plugins to Ant/Maven (which I think +most projects would be using) it
> should not +be any harder to distribute an application to the server
> than it is to copy it into a directory. +By using a command the
> developers/admin can see if the operation worked without scanning the
> server +logs for errors. It also avoids all the problems with the
> scanner hitting partially copied files, +race conditions between seeing
> the module and the plan, being able to revert if it failed, and so
> forth. +

For what it's worth, I think you're arguing for correctness over 
convenience.  While that's nice in admin tools, I'm not sure it's really a 
win for development tools, and certainly not for initially attempting to 
attract new developers.

For what it's worth, I can't recall having a problem with Tomcat,
JBoss or WebLogic where it processed a partially copied file or had a race
condition or was unable to revert or it was unclear to me whether the
application was successfully deployed (either you get big stack traces or
you don't).  So I think we can solve those problems.

More importantly, the first time any J2EE developer sits down
with a new server, I bet they try to deploy some app they have sitting
around, and I bet they try to do it by dumping it in the deploy directory.  
Now we can teach them to use a tool instead, but I think in rejecting a
hot deploy directory you're introducing a hurdle to adoption (must consult
doucmentation and learn tool syntax and set up tool execution environment)
because you don't like the standard process.

But, all that said, I hope to make the deployment tool convenient 
enough that it's not a very big hurdle.

Aaron

Re: How to updated config.list during offline deployment

[Aaron Mulder]

What I am proposing is the equivalent of using the current deploy 
tool, and then adding the module's configId to the server command line 
next time you start it -- which is what you can do today.  I don't see how 
that makes the situation worse.

You seem to be sugesting that the deploy tool should only work
fully when the server is running, and if the server is not running, then
you need to use a different command to start the server and deploy at the
same time.  Is that right?

Aaron

On Thu, 4 Nov 2004, Jeremy Boynes wrote:
> You mean, you hope that it starts - you would have to look at the server 
> to see if it actually did. So this has the same "copy-and-pray" utility 
> as dumping the module in a directory.
> 
> I think either you would be checking as you watched the server start 
> (the --add option) or you would test by pinging the server once it had 
> started. The latter option here is exactly as hard as just calling "start"
> 
> My issue is the ambiguity in the outcome of what you propose.

Re: Calling all Early(?) adopters

[David Blevins]

Don't you mean M4?  We just voted to release M3 now.
-David
On Nov 4, 2004, at 8:49 AM, Davanum Srinivas wrote:
Dear Early Adopters,
If you have tried Geronimo already (or in the process of doing so),
please let us know how we can make it easier Out-Of-The-Box for
everyone...Here are some things we jotted down to get the ball
rolling:
http://wiki.apache.org/geronimo/WishList/M3
thanks,
dims
--
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: How to updated config.list during offline deployment

[Jeremy Boynes]

Aaron Mulder wrote:
	If you "deploy" to a server that's not running, then the module 
will be started next time the server starts.  If you "distribute" to a 
server that's not running, then the module will not be started next time 
the server starts.

You mean, you hope that it starts - you would have to look at the server 
to see if it actually did. So this has the same "copy-and-pray" utility 
as dumping the module in a directory.

I think either you would be checking as you watched the server start 
(the --add option) or you would test by pinging the server once it had 
started. The latter option here is exactly as hard as just calling "start"

My issue is the ambiguity in the outcome of what you propose.
--
Jeremy

Re: How to updated config.list during offline deployment

[Aaron Mulder]

On Thu, 4 Nov 2004, Jeremy Boynes wrote:
> Pardon me for being dumb but how can you start a module if the server is 
> down?
> 
> I think we may be trying to hard to kludge 88-style operations into a 
> mode that 88 was not intended to support.

If you "deploy" to a server that's not running, then the module 
will be started next time the server starts.  If you "distribute" to a 
server that's not running, then the module will not be started next time 
the server starts.

The alternative is to have two tools for online/offline mode (you 
missed the boat if you intend to fight for that), or one tool where only 
half the options work any any given time (ick).

Aaron

Re: Calling all Early(?) adopters

[Peter Nabbefeld]

Hi,
I just want to try M3 with Tomcat and Apache web server. I've running 
Tomcat with the web server, now I'd need step-by-step instructions (1.) 
to get geronimo running with my installation (2.) how to deploy an 
application into geronimo (especially for additional geronimo 
configuration files).

Kind regards
Peter Nabbefeld
Davanum Srinivas schrieb:
Dear Early Adopters,
If you have tried Geronimo already (or in the process of doing so),
please let us know how we can make it easier Out-Of-The-Box for
everyone...Here are some things we jotted down to get the ball
rolling:
http://wiki.apache.org/geronimo/WishList/M3
thanks,
dims

Re: How to updated config.list during offline deployment

[Jeremy Boynes]

Aaron Mulder wrote:
	I'm working on the new deployer not the old one.  As per the
"proposed deployer syntax" message, this one actually offers a JSR-88
start method while the server is not running, which equates to updating
the config list to include the module.  I'd rather not start the server to 
do that...  Also, the bulk of the feedback on the thread before that was 
that having two tools to handle deployment tasks was bad.

Pardon me for being dumb but how can you start a module if the server is 
down?

I think we may be trying to hard to kludge 88-style operations into a 
mode that 88 was not intended to support.

--
Jeremy

Re: How to updated config.list during offline deployment

[Aaron Mulder]

Actually, it will be

java -jar bin/deployer.jar deploy [module] [plan]

As per the proposed deployer syntax thread.  (Though I currently
have a separate new-deployer.jar until we feel comfortable axing the old
one).

Aaron

On Thu, 4 Nov 2004, Dain Sundstrom wrote:
> So I would have to do this:
> 
> java -jar bin/server.jar --install file.ear
> java -jar bin/server.jar --add my/new/config
> 
> I think that the vast majority of the time I would just want this:
> 
> java -jar bin/server.jar --deploy file.ear
> 
> which would do both of the above commands in one go
> 
> -dain
> 
> 

Re: How to updated config.list during offline deployment

[Aaron Mulder]

I'm working on the new deployer not the old one.  As per the
"proposed deployer syntax" message, this one actually offers a JSR-88
start method while the server is not running, which equates to updating
the config list to include the module.  I'd rather not start the server to 
do that...  Also, the bulk of the feedback on the thread before that was 
that having two tools to handle deployment tasks was bad.

Aaron

On Thu, 4 Nov 2004, Jeremy Boynes wrote:
> The other thing is that the --install option does just that - install 
> but not start (it is meant to be similar to JSR-88 distribute).
> 
> I believe this can be better solved by adding an option to server.jar 
> that adds a new configId to the list to be run, something like:
> 
> java -jar bin/server.jar --add my/new/config
> 
> --
> Jeremy
> 

Re: How to updated config.list during offline deployment

[Dain Sundstrom]

On Nov 4, 2004, at 11:18 AM, Jeremy Boynes wrote:
Aaron Mulder wrote:
	I'd like to be able to add entries to config.list when the server is 
not running and I'm doing a deployment.  The problem is, the 
configuration list GBean isn't running -- it's not in the minimal set 
started by the deployer.  And even if it was, it would install a 
shutdown hook that basically saved an empty file when the deployer 
finished.
	Anyone mind if I just have a little logic in the deployer to update 
this file directly?
Yes, I mind. The config.list file is specific to the actual 
implementation of the PersistentConfigurationList GBean and the 
deployer should not assume that as other implementations may exist.

The other thing is that the --install option does just that - install 
but not start (it is meant to be similar to JSR-88 distribute).

I believe this can be better solved by adding an option to server.jar 
that adds a new configId to the list to be run, something like:

java -jar bin/server.jar --add my/new/config
So I would have to do this:
java -jar bin/server.jar --install file.ear
java -jar bin/server.jar --add my/new/config
I think that the vast majority of the time I would just want this:
java -jar bin/server.jar --deploy file.ear
which would do both of the above commands in one go
-dain

change: ServerInfo baseDirectory

[Dain Sundstrom]

The addition of GBean persistence has revealed a problem in ServerInfo 
(http://nagoya.apache.org/jira/browse/GERONIMO-431).  The problem is 
that normally we guess the location of the geronimo home directory, and 
this location is saved as an absolute path during gbean persistence.  
This means that if an admin were to boot a geronimo install in a 
directory they would never be able to move the install.

The real cause of this problem is we have no place to save a 
user-set-home-directory that is different from the 
working-home-directory (the one we guessed when the user set home 
directory is null).

The fix for this I have implemented is have the getBaseDirectory to 
return only the user-set-base-directory, which in a normal case this 
method return null.  This does not cause any code in geronimo, openejb, 
activemq to break, because all of these modules use one of the resolve 
methods on ServerInfo directly instead of trying to resolve paths 
themselves.

For anyone using, ServerInfo in a GBean not inside of geronimo, you 
will need to check for uses if getBaseDirectory or 
Kernel.getAttribute("baseDirectory").

I'll be checking this in shortly
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26

Re: How to updated config.list during offline deployment

[Jeremy Boynes]

Aaron Mulder wrote:
	I'd like to be able to add entries to config.list when the server 
is not running and I'm doing a deployment.  The problem is, the 
configuration list GBean isn't running -- it's not in the minimal set 
started by the deployer.  And even if it was, it would install a shutdown 
hook that basically saved an empty file when the deployer finished.

	Anyone mind if I just have a little logic in the deployer to 
update this file directly?
Yes, I mind. The config.list file is specific to the actual 
implementation of the PersistentConfigurationList GBean and the deployer 
should not assume that as other implementations may exist.

The other thing is that the --install option does just that - install 
but not start (it is meant to be similar to JSR-88 distribute).

I believe this can be better solved by adding an option to server.jar 
that adds a new configId to the list to be run, something like:

java -jar bin/server.jar --add my/new/config
--
Jeremy

Re: How to updated config.list during offline deployment

[Dain Sundstrom]

On Nov 4, 2004, at 10:39 AM, Aaron Mulder wrote:
	I'd like to be able to add entries to config.list when the server
is not running and I'm doing a deployment.  The problem is, the
configuration list GBean isn't running -- it's not in the minimal set
started by the deployer.  And even if it was, it would install a 
shutdown
hook that basically saved an empty file when the deployer finished.

Anyone mind if I just have a little logic in the deployer to
update this file directly?
+1
Can you also try to grab an NIO lock on the file, so we can prevent two 
deployers trying to update it at the same time?  Actually, I think the 
server should grab a lock on start up, to stop offline deployers 
messing with the index while the server is running, since the server 
will overwrite it on shutdown.

-dain

How to updated config.list during offline deployment

[Aaron Mulder]

I'd like to be able to add entries to config.list when the server 
is not running and I'm doing a deployment.  The problem is, the 
configuration list GBean isn't running -- it's not in the minimal set 
started by the deployer.  And even if it was, it would install a shutdown 
hook that basically saved an empty file when the deployer finished.

Anyone mind if I just have a little logic in the deployer to 
update this file directly?

Aaron

Re: Zip Files and Endian-ness

[Dain Sundstrom]

The endianness should not matter when reading the byte, but I could be 
wrong.  Anyway, I got the same results on my mac:

B1: 50
B2: 4b
B3: 3
B4: 4
Int: 504b0304
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Nov 4, 2004, at 10:02 AM, Aaron Mulder wrote:
	I'm trying to detect a Zip file.  On an Intel/AMD platform, the
first 4 bytes are (hex) 50-4b-03-04.  I wonder if the order is 
different
on a differently-endian platform.  Can someone look at a ZIP file on,
what, a Solaris box I guess, and let me know what order the first 4 
bytes
are?  Maybe a Mac is different?  I forget.  Here's a little test class.

Thanks,
Aaron
import java.io.*;
public class ZipTest {
public static void main(String[] args) {
try {
FileInputStream in = new FileInputStream(args[0]);
System.out.println("B1: "+Integer.toHexString(in.read()));
System.out.println("B2: "+Integer.toHexString(in.read()));
System.out.println("B3: "+Integer.toHexString(in.read()));
System.out.println("B4: "+Integer.toHexString(in.read()));
in.close();
in = new FileInputStream(args[0]);
System.out.println("Int: "+Integer.toHexString(
new DataInputStream(in).readInt()));
in.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
PC Results
--
B1: 50
B2: 4b
B3: 3
B4: 4
Int: 504b0304

[jira] Assigned: (GERONIMO-433) Tolerate non-Sun JREs

[Alan Cabrera (JIRA)]

 [ http://nagoya.apache.org/jira/browse/GERONIMO-433?page=history ]

Alan Cabrera reassigned GERONIMO-433:
-

Assign To: Alan Cabrera

> Tolerate non-Sun JREs
> -
>
>  Key: GERONIMO-433
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-433
>  Project: Apache Geronimo
> Type: Improvement
>   Components: general
> Reporter: Glyn Normington
> Assignee: Alan Cabrera
> Priority: Critical

>
> Geronimo fails to build against a non-Sun JRE (e.g. IBM's) because of the use 
> of non-standard Sun internal classes (in com.sun.* packages) such as 
> com.sun.security.jgss.GSSUtil. The build stops with:
> A compilation error occurred in the network module:
> C:\apache\geronimo\modules\network\src\java\org\apache\geronimo\network\protocol\GSSAPIServerProtocol.java:29:
> package com.sun.security.jgss does not exist import 
> com.sun.security.jgss.GSSUtil;
> grep also found the following other references to com.sun in Java files, some 
> of which will need to be modified to tolerate non-Sun JREs.
> modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:
> System.setProperty("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/connector/src/test/org/apache/geronimo/connector/outbound/ManagedConnectionFactoryWrapperTest.java:
> env.put("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/geronimo/GeronimoRootContextTest.java:
> System.setProperty("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/java/AbstractContextTest.java:
> System.setProperty("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/java/ThreadContextTest.java:
> System.setProperty("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/security/src/java/org/apache/geronimo/security/realm/providers/KerberosSecurityRealm.java:
> AppConfigurationEntry entry = new 
> AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
> modules/security/src/test/org/apache/geronimo/security/jaas/LoginKerberosNonGeronimoTest.java:
> gbean.setAttribute("loginModuleName", 
> "com.sun.security.auth.module.Krb5LoginModule");
> modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java:import
>  com.sun.security.auth.login.ConfigFile;
> modules/system/src/test/org/apache/geronimo/system/properties/NamingPropertiesTest.java:
> private static final String NAMING_FACTORY_INITIAL = 
> "com.sun.jndi.rmi.registry.RegistryContextFactory";

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Zip Files and Endian-ness

[Aaron Mulder]

I'm trying to detect a Zip file.  On an Intel/AMD platform, the 
first 4 bytes are (hex) 50-4b-03-04.  I wonder if the order is different 
on a differently-endian platform.  Can someone look at a ZIP file on, 
what, a Solaris box I guess, and let me know what order the first 4 bytes 
are?  Maybe a Mac is different?  I forget.  Here's a little test class.

Thanks,
Aaron

import java.io.*;
public class ZipTest {
public static void main(String[] args) {
try {
FileInputStream in = new FileInputStream(args[0]);
System.out.println("B1: "+Integer.toHexString(in.read()));
System.out.println("B2: "+Integer.toHexString(in.read()));
System.out.println("B3: "+Integer.toHexString(in.read()));
System.out.println("B4: "+Integer.toHexString(in.read()));
in.close();
in = new FileInputStream(args[0]);
System.out.println("Int: "+Integer.toHexString(
new DataInputStream(in).readInt()));
in.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}

PC Results
--
B1: 50
B2: 4b
B3: 3
B4: 4
Int: 504b0304

[jira] Created: (GERONIMO-435) Should be able to specifiy default parent config id

[Jeremy Boynes (JIRA)]

Should be able to specifiy default parent config id
---

 Key: GERONIMO-435
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-435
 Project: Apache Geronimo
Type: Improvement
Reporter: Jeremy Boynes
 Assigned to: Jeremy Boynes 


The default parentId in the deployer is hard wired to 
org/apache/geronimo/Server. It would be useful if this could be customized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-433) Tolerate non-Sun JREs

[Aaron Mulder (JIRA)]

 [ 
http://nagoya.apache.org/jira/browse/GERONIMO-433?page=comments#action_55049 ]
 
Aaron Mulder commented on GERONIMO-433:
---

The Geronimo Jetty HTTPSConnector also assumes Sun's JRE (by using the Sun JSSE 
provider).  I believe Jetty has a generic JSSE connector too, but I don't know 
what features might be different.

> Tolerate non-Sun JREs
> -
>
>  Key: GERONIMO-433
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-433
>  Project: Apache Geronimo
> Type: Improvement
>   Components: general
> Reporter: Glyn Normington
> Priority: Critical

>
> Geronimo fails to build against a non-Sun JRE (e.g. IBM's) because of the use 
> of non-standard Sun internal classes (in com.sun.* packages) such as 
> com.sun.security.jgss.GSSUtil. The build stops with:
> A compilation error occurred in the network module:
> C:\apache\geronimo\modules\network\src\java\org\apache\geronimo\network\protocol\GSSAPIServerProtocol.java:29:
> package com.sun.security.jgss does not exist import 
> com.sun.security.jgss.GSSUtil;
> grep also found the following other references to com.sun in Java files, some 
> of which will need to be modified to tolerate non-Sun JREs.
> modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:
> System.setProperty("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/connector/src/test/org/apache/geronimo/connector/outbound/ManagedConnectionFactoryWrapperTest.java:
> env.put("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/geronimo/GeronimoRootContextTest.java:
> System.setProperty("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/java/AbstractContextTest.java:
> System.setProperty("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/naming/src/test/org/apache/geronimo/naming/java/ThreadContextTest.java:
> System.setProperty("java.naming.factory.initial", 
> "com.sun.jndi.rmi.registry.RegistryContextFactory");
> modules/security/src/java/org/apache/geronimo/security/realm/providers/KerberosSecurityRealm.java:
> AppConfigurationEntry entry = new 
> AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
> modules/security/src/test/org/apache/geronimo/security/jaas/LoginKerberosNonGeronimoTest.java:
> gbean.setAttribute("loginModuleName", 
> "com.sun.security.auth.module.Krb5LoginModule");
> modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java:import
>  com.sun.security.auth.login.ConfigFile;
> modules/system/src/test/org/apache/geronimo/system/properties/NamingPropertiesTest.java:
> private static final String NAMING_FACTORY_INITIAL = 
> "com.sun.jndi.rmi.registry.RegistryContextFactory";

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-434) Connection factories extracted from conceptually wrong gbean

[David Jencks (JIRA)]

 [ http://nagoya.apache.org/jira/browse/GERONIMO-434?page=history ]

David Jencks updated GERONIMO-434:
--

Component: connector

> Connection factories extracted from conceptually wrong gbean
> 
>
>  Key: GERONIMO-434
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-434
>  Project: Apache Geronimo
> Type: Bug
>   Components: connector
> Versions: 1.0-M2
> Reporter: David Jencks
> Assignee: David Jencks

>
> Currently connection factories/datasources (or their proxies) are obtained 
> from the JCAManagedConnectionFactory gbean.  Since there is a 
> ConnectionFactory/Datasource gbean for the jsr-77 requirements, it would make 
> more sense to obtain the connection factory/datasource from there.  This 
> would have the additional feature of allowing one to set up several 
> connection factories under different names that all use the same 
> ConnectionManager and ManagedConnectionFactory.  This would for instance let 
> you set up separately named QueueConnectionFactory and TopicConnectionFactory 
> that share the same connections: named appropriately, this can let you leave 
> out resource-refs in plans for apps that call the factories different names.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-434) Connection factories extracted from conceptually wrong gbean

[David Jencks (JIRA)]

Connection factories extracted from conceptually wrong gbean


 Key: GERONIMO-434
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-434
 Project: Apache Geronimo
Type: Bug
Versions: 1.0-M2
Reporter: David Jencks
 Assigned to: David Jencks 


Currently connection factories/datasources (or their proxies) are obtained from 
the JCAManagedConnectionFactory gbean.  Since there is a 
ConnectionFactory/Datasource gbean for the jsr-77 requirements, it would make 
more sense to obtain the connection factory/datasource from there.  This would 
have the additional feature of allowing one to set up several connection 
factories under different names that all use the same ConnectionManager and 
ManagedConnectionFactory.  This would for instance let you set up separately 
named QueueConnectionFactory and TopicConnectionFactory that share the same 
connections: named appropriately, this can let you leave out resource-refs in 
plans for apps that call the factories different names.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-433) Tolerate non-Sun JREs

[Glyn Normington (JIRA)]

Tolerate non-Sun JREs
-

 Key: GERONIMO-433
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-433
 Project: Apache Geronimo
Type: Improvement
  Components: general  
Reporter: Glyn Normington
Priority: Critical


Geronimo fails to build against a non-Sun JRE (e.g. IBM's) because of the use 
of non-standard Sun internal classes (in com.sun.* packages) such as 
com.sun.security.jgss.GSSUtil. The build stops with:

A compilation error occurred in the network module:

C:\apache\geronimo\modules\network\src\java\org\apache\geronimo\network\protocol\GSSAPIServerProtocol.java:29:
package com.sun.security.jgss does not exist import 
com.sun.security.jgss.GSSUtil;

grep also found the following other references to com.sun in Java files, some 
of which will need to be modified to tolerate non-Sun JREs.

modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:
System.setProperty("java.naming.factory.initial", 
"com.sun.jndi.rmi.registry.RegistryContextFactory");

modules/connector/src/test/org/apache/geronimo/connector/outbound/ManagedConnectionFactoryWrapperTest.java:
env.put("java.naming.factory.initial", 
"com.sun.jndi.rmi.registry.RegistryContextFactory");

modules/naming/src/test/org/apache/geronimo/naming/geronimo/GeronimoRootContextTest.java:
System.setProperty("java.naming.factory.initial", 
"com.sun.jndi.rmi.registry.RegistryContextFactory");

modules/naming/src/test/org/apache/geronimo/naming/java/AbstractContextTest.java:
System.setProperty("java.naming.factory.initial", 
"com.sun.jndi.rmi.registry.RegistryContextFactory");

modules/naming/src/test/org/apache/geronimo/naming/java/ThreadContextTest.java: 
   System.setProperty("java.naming.factory.initial", 
"com.sun.jndi.rmi.registry.RegistryContextFactory");

modules/security/src/java/org/apache/geronimo/security/realm/providers/KerberosSecurityRealm.java:
AppConfigurationEntry entry = new 
AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",

modules/security/src/test/org/apache/geronimo/security/jaas/LoginKerberosNonGeronimoTest.java:
gbean.setAttribute("loginModuleName", 
"com.sun.security.auth.module.Krb5LoginModule");

modules/security/src/test/org/apache/geronimo/security/network/protocol/SubjectCarryingProtocolTest.java:import
 com.sun.security.auth.login.ConfigFile;

modules/system/src/test/org/apache/geronimo/system/properties/NamingPropertiesTest.java:
private static final String NAMING_FACTORY_INITIAL = 
"com.sun.jndi.rmi.registry.RegistryContextFactory";




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Calling all Early(?) adopters

[Davanum Srinivas]

Dear Early Adopters,

If you have tried Geronimo already (or in the process of doing so),
please let us know how we can make it easier Out-Of-The-Box for
everyone...Here are some things we jotted down to get the ball
rolling:
http://wiki.apache.org/geronimo/WishList/M3

thanks,
dims

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

[jira] Commented: (GERONIMO-334) cannot find tools.jar at server startup

[Dain Sundstrom (JIRA)]

 [ 
http://nagoya.apache.org/jira/browse/GERONIMO-334?page=comments#action_55044 ]
 
Dain Sundstrom commented on GERONIMO-334:
-

Yes.  My primary motivation for working on switching to the eclipse compiler 
was so we would no longer need the tools.jar hack.

> cannot find tools.jar at server startup
> ---
>
>  Key: GERONIMO-334
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-334
>  Project: Apache Geronimo
> Type: Bug
> Versions: 1.0-M2
>  Environment: red hat linux 9, kernel 2.4.2
> Reporter: karan singh malhi
> Priority: Trivial

>
> At server startup, i get a warning that tools.jar not found under 
> JAVA_HOME/lib. My tools.jar is both under JAVA_HOME/lib as well as under 
> JAVA_HOME/lib/ext.  Why cant it find it. Please see the trace below:- 
> [EMAIL PROTECTED] geronimo-1.0-M2]$ java -jar bin/server.jar 
> your/domain/name/Example
> 21:02:04,037 WARN  [ToolsJarHack] Could not all find java compiler: tools.jar 
> file not found at /usr/local/share/install/j2sdk1.4.2_04/jre/lib/tools.jar
> 21:02:04,045 INFO  [Daemon] Server startup begun
> 21:02:04,827 INFO  [Kernel] Starting boot
> 21:02:05,113 INFO  [MBeanServerFactory] Created MBeanServer with ID: 
> 1db7df8:ff4cdbab1a:-8000:j2ee:1
> 21:02:05,316 INFO  [Kernel] Booted
> 21:02:05,432 INFO  [ConfigurationManagerImpl] Loaded Configuration 
> geronimo.config:name="org/apache/geronimo/System"
> 21:02:06,088 INFO  [Configuration] Started configuration 
> org/apache/geronimo/System
> 21:02:06,152 INFO  [RMIRegistryService] Started RMI Registry on port 1099
> 21:02:06,233 INFO  [ReadOnlyRepository] Repository root is 
> file:/home/karan/geronimo-1.0-M2/repository/
> 21:02:06,304 INFO  [ConfigurationManagerImpl] Loaded Configuration 
> geronimo.config:name="your/domain/name/Example"
> 21:02:06,338 INFO  [ConfigurationManagerImpl] Loaded Configuration 
> geronimo.config:name="org/apache/geronimo/Server"
> 21:02:12,054 INFO  [Configuration] Started configuration 
> org/apache/geronimo/Server
> 21:02:13,166 INFO  [Configuration] Started configuration 
> your/domain/name/Example
> 21:02:14,214 INFO  [LoginService] Login server has been started
> 21:02:14,241 INFO  [ThreadPool] Thread pool DefaultThreadPool started
> 21:02:14,279 INFO  [SecurityServiceMBean] Security service started
> 21:02:14,284 INFO  [HttpServer] Starting Jetty/5.0.RC0
> 21:02:14,293 INFO  [HttpServer] Started [EMAIL PROTECTED]
> 21:02:14,307 INFO  [SocketListener] Started SocketListener on 0.0.0.0:8080
> 21:02:16,210 INFO  [HOWLLog] Initiating transaction manager recovery
> 21:02:17,158 INFO  [HOWLLog] In doubt transactions recovered from log
> 21:02:17,252 INFO  [PropertiesFileSecurityRealm] Properties File Realm - 
> geronimo-properties-realm - refresh
> 21:02:17,253 INFO  [PropertiesFileSecurityRealm] Properties File Realm - 
> geronimo-properties-realm - started
> 21:02:17,414 INFO  [Credential] Checking Resource aliases
> 21:02:19,469 INFO  [HttpContext] Started 
> WebApplicationContext[/test,file:/home/karan/geronimo-1.0-M2/config-store/10/war/]
> 21:02:19,663 INFO  [JettyWebAppContext] JettyWebAppContext started
> 21:02:19,950 INFO  [RMIConnectorServer] RMIConnectorServer started at: 
> service:jmx:rmi://localhost/jndi/rmi:/JMXConnector
> 21:02:19,952 INFO  [server:name=localhost,role=JMXService] Started 
> JMXConnector service:jmx:rmi://localhost/jndi/rmi:/JMXConnector
> 21:02:19,957 INFO  [Daemon] Server startup completed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Re: Commons Logging problem?

[Aaron Mulder]

It works for me now.  Thank you very much!

I guess maybe one of our (by which I mean David B's) standard
builds should wipe out its maven repository before building.  The "first
time developer" experience.

Aaron

On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> Yoohoo!!! Fixed it. adding a rm -rf to my build script to make sure
> this does not happen again.
> 
> thanks,
> dims
> 
> 
> On Thu, 4 Nov 2004 08:12:25 -0500 (EST), Aaron Mulder
> <[EMAIL PROTECTED]> wrote:
> > Can you first grep
> > modules/axis/target/generated/samples/echo-war/build.xml for logging and
> > see if you have an include for it?
> > 
> > Thanks,
> > 
> > 
> > Aaron
> > 
> > On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> > > hmmm...let me check by cleaning up my axis repo.
> > >
> > >
> > > On Thu, 4 Nov 2004 08:08:12 -0500 (EST), Aaron Mulder
> > > <[EMAIL PROTECTED]> wrote:
> > > > No, never mind, I jsut had a corrupted EWS download that time.
> > > >
> > > > OK, so how I'm looking at the build script for
> > > > modules/axis/target/generated/samples/echo-war/build.xml
> > > >
> > > > It doesn't list commons-logging in the 
> > > > section.  If you still have a commons-logging in
> > > > ~/.maven/repository/axis/jars then it will work, but I don't.
> > > >
> > > >
> > > >
> > > > Aaron
> > > >
> > > > On Thu, 4 Nov 2004, Aaron Mulder wrote:
> > > > >   Believe it or not, it looks like only the first JAR in the
> > > > > dependency list is getting onto the classpath.  When I put a little
> > > > > wrapper JAR there first, none of the EWS stuff could be loaded.  If I 
> > > > > take
> > > > > that away, EWS is first and Logging can't be loaded.  I need to 
> > > > > figure out
> > > > > WTF is going on with this environment.  Sorry for taking so much of 
> > > > > your
> > > > > time on it!
> > > > >
> > > > > Aaron
> > > > >
> > > > > On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> > > > > > Aaron,
> > > > > >
> > > > > > Here's my paste: http://rafb.net/paste/results/I89rnj81.html. If you
> > > > > > look closely, there's some problem loading commons logging stuff in
> > > > > > your environment.
> > > > > >
> > > > > > 24:   [java] [DEBUG] Finding class 
> > > > > > org.apache.commons.logging.LogFactory
> > > > > > 25:   [java] [DEBUG] Class org.apache.commons.logging.LogFactory
> > > > > > loaded from ant loader
> > > > > > 26:   [java] [DEBUG] Class java.security.PrivilegedAction loaded 
> > > > > > from
> > > > > > parent loader
> > > > > > 27:   [java] [DEBUG] Finding class
> > > > > > org.apache.commons.logging.LogConfigurationException
> > > > > >
> > > > > > On my line 25: maven/ant is able to load the
> > > > > > org.apache.commons.logging.LogFactory class.
> > > > > >
> > > > > > 24:   [java] [DEBUG] Finding class 
> > > > > > org.apache.commons.logging.LogFactory
> > > > > > 25:   [java] [ERROR] java.lang.NoClassDefFoundError
> > > > > > 26:   [ant] [DEBUG]  +User task: propertyfile
> > > > > > org.apache.tools.ant.taskdefs.optional.PropertyFile
> > > > > > 27:   [ant] [DEBUG]  +User task: vsscheckin
> > > > > > org.apache.tools.ant.taskdefs.optional.vss.MSVSSCHECKIN
> > > > > >
> > > > > > while on your line 25 (http://rafb.net/paste/results/I89rnj81.html)
> > > > > > there's a java.lang.NoClassDefFoundError...so i believe you have a
> > > > > > rogus commons-logging somewhere that is causing this problem. As you
> > > > > > mentioed you don't have a problem running the
> > > > > > "org.apache.geronimo.ews.ws4j2ee.utils.packager.Packager" task from
> > > > > > the command line which further reinforces this notion of mine.
> > > > > >
> > > > > > -- dims
> > > > > >
> > > > > > --
> > > > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > >
> > 
> 
> 
> -- 
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 

Re: Commons Logging problem?

[Davanum Srinivas]

Yoohoo!!! Fixed it. adding a rm -rf to my build script to make sure
this does not happen again.

thanks,
dims


On Thu, 4 Nov 2004 08:12:25 -0500 (EST), Aaron Mulder
<[EMAIL PROTECTED]> wrote:
> Can you first grep
> modules/axis/target/generated/samples/echo-war/build.xml for logging and
> see if you have an include for it?
> 
> Thanks,
> 
> 
> Aaron
> 
> On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> > hmmm...let me check by cleaning up my axis repo.
> >
> >
> > On Thu, 4 Nov 2004 08:08:12 -0500 (EST), Aaron Mulder
> > <[EMAIL PROTECTED]> wrote:
> > > No, never mind, I jsut had a corrupted EWS download that time.
> > >
> > > OK, so how I'm looking at the build script for
> > > modules/axis/target/generated/samples/echo-war/build.xml
> > >
> > > It doesn't list commons-logging in the 
> > > section.  If you still have a commons-logging in
> > > ~/.maven/repository/axis/jars then it will work, but I don't.
> > >
> > >
> > >
> > > Aaron
> > >
> > > On Thu, 4 Nov 2004, Aaron Mulder wrote:
> > > >   Believe it or not, it looks like only the first JAR in the
> > > > dependency list is getting onto the classpath.  When I put a little
> > > > wrapper JAR there first, none of the EWS stuff could be loaded.  If I 
> > > > take
> > > > that away, EWS is first and Logging can't be loaded.  I need to figure 
> > > > out
> > > > WTF is going on with this environment.  Sorry for taking so much of your
> > > > time on it!
> > > >
> > > > Aaron
> > > >
> > > > On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> > > > > Aaron,
> > > > >
> > > > > Here's my paste: http://rafb.net/paste/results/I89rnj81.html. If you
> > > > > look closely, there's some problem loading commons logging stuff in
> > > > > your environment.
> > > > >
> > > > > 24:   [java] [DEBUG] Finding class 
> > > > > org.apache.commons.logging.LogFactory
> > > > > 25:   [java] [DEBUG] Class org.apache.commons.logging.LogFactory
> > > > > loaded from ant loader
> > > > > 26:   [java] [DEBUG] Class java.security.PrivilegedAction loaded from
> > > > > parent loader
> > > > > 27:   [java] [DEBUG] Finding class
> > > > > org.apache.commons.logging.LogConfigurationException
> > > > >
> > > > > On my line 25: maven/ant is able to load the
> > > > > org.apache.commons.logging.LogFactory class.
> > > > >
> > > > > 24:   [java] [DEBUG] Finding class 
> > > > > org.apache.commons.logging.LogFactory
> > > > > 25:   [java] [ERROR] java.lang.NoClassDefFoundError
> > > > > 26:   [ant] [DEBUG]  +User task: propertyfile
> > > > > org.apache.tools.ant.taskdefs.optional.PropertyFile
> > > > > 27:   [ant] [DEBUG]  +User task: vsscheckin
> > > > > org.apache.tools.ant.taskdefs.optional.vss.MSVSSCHECKIN
> > > > >
> > > > > while on your line 25 (http://rafb.net/paste/results/I89rnj81.html)
> > > > > there's a java.lang.NoClassDefFoundError...so i believe you have a
> > > > > rogus commons-logging somewhere that is causing this problem. As you
> > > > > mentioed you don't have a problem running the
> > > > > "org.apache.geronimo.ews.ws4j2ee.utils.packager.Packager" task from
> > > > > the command line which further reinforces this notion of mine.
> > > > >
> > > > > -- dims
> > > > >
> > > > > --
> > > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > > >
> > > >
> > >
> >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Commons Logging problem?

[Davanum Srinivas]

hmmm...let me check by cleaning up my axis repo.


On Thu, 4 Nov 2004 08:08:12 -0500 (EST), Aaron Mulder
<[EMAIL PROTECTED]> wrote:
> No, never mind, I jsut had a corrupted EWS download that time.
> 
> OK, so how I'm looking at the build script for
> modules/axis/target/generated/samples/echo-war/build.xml
> 
> It doesn't list commons-logging in the 
> section.  If you still have a commons-logging in
> ~/.maven/repository/axis/jars then it will work, but I don't.
> 
> 
> 
> Aaron
> 
> On Thu, 4 Nov 2004, Aaron Mulder wrote:
> >   Believe it or not, it looks like only the first JAR in the
> > dependency list is getting onto the classpath.  When I put a little
> > wrapper JAR there first, none of the EWS stuff could be loaded.  If I take
> > that away, EWS is first and Logging can't be loaded.  I need to figure out
> > WTF is going on with this environment.  Sorry for taking so much of your
> > time on it!
> >
> > Aaron
> >
> > On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> > > Aaron,
> > >
> > > Here's my paste: http://rafb.net/paste/results/I89rnj81.html. If you
> > > look closely, there's some problem loading commons logging stuff in
> > > your environment.
> > >
> > > 24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
> > > 25:   [java] [DEBUG] Class org.apache.commons.logging.LogFactory
> > > loaded from ant loader
> > > 26:   [java] [DEBUG] Class java.security.PrivilegedAction loaded from
> > > parent loader
> > > 27:   [java] [DEBUG] Finding class
> > > org.apache.commons.logging.LogConfigurationException
> > >
> > > On my line 25: maven/ant is able to load the
> > > org.apache.commons.logging.LogFactory class.
> > >
> > > 24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
> > > 25:   [java] [ERROR] java.lang.NoClassDefFoundError
> > > 26:   [ant] [DEBUG]  +User task: propertyfile
> > > org.apache.tools.ant.taskdefs.optional.PropertyFile
> > > 27:   [ant] [DEBUG]  +User task: vsscheckin
> > > org.apache.tools.ant.taskdefs.optional.vss.MSVSSCHECKIN
> > >
> > > while on your line 25 (http://rafb.net/paste/results/I89rnj81.html)
> > > there's a java.lang.NoClassDefFoundError...so i believe you have a
> > > rogus commons-logging somewhere that is causing this problem. As you
> > > mentioed you don't have a problem running the
> > > "org.apache.geronimo.ews.ws4j2ee.utils.packager.Packager" task from
> > > the command line which further reinforces this notion of mine.
> > >
> > > -- dims
> > >
> > > --
> > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > >
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Commons Logging problem?

[Aaron Mulder]

No, never mind, I jsut had a corrupted EWS download that time.

OK, so how I'm looking at the build script for 
modules/axis/target/generated/samples/echo-war/build.xml

It doesn't list commons-logging in the 
section.  If you still have a commons-logging in 
~/.maven/repository/axis/jars then it will work, but I don't.

Aaron

On Thu, 4 Nov 2004, Aaron Mulder wrote:
>   Believe it or not, it looks like only the first JAR in the
> dependency list is getting onto the classpath.  When I put a little
> wrapper JAR there first, none of the EWS stuff could be loaded.  If I take
> that away, EWS is first and Logging can't be loaded.  I need to figure out
> WTF is going on with this environment.  Sorry for taking so much of your
> time on it!
> 
> Aaron
> 
> On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> > Aaron,
> > 
> > Here's my paste: http://rafb.net/paste/results/I89rnj81.html. If you
> > look closely, there's some problem loading commons logging stuff in
> > your environment.
> > 
> > 24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
> > 25:   [java] [DEBUG] Class org.apache.commons.logging.LogFactory
> > loaded from ant loader
> > 26:   [java] [DEBUG] Class java.security.PrivilegedAction loaded from
> > parent loader
> > 27:   [java] [DEBUG] Finding class
> > org.apache.commons.logging.LogConfigurationException
> > 
> > On my line 25: maven/ant is able to load the
> > org.apache.commons.logging.LogFactory class.
> > 
> > 24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
> > 25:   [java] [ERROR] java.lang.NoClassDefFoundError
> > 26:   [ant] [DEBUG]  +User task: propertyfile
> > org.apache.tools.ant.taskdefs.optional.PropertyFile
> > 27:   [ant] [DEBUG]  +User task: vsscheckin
> > org.apache.tools.ant.taskdefs.optional.vss.MSVSSCHECKIN
> > 
> > while on your line 25 (http://rafb.net/paste/results/I89rnj81.html)
> > there's a java.lang.NoClassDefFoundError...so i believe you have a
> > rogus commons-logging somewhere that is causing this problem. As you
> > mentioed you don't have a problem running the
> > "org.apache.geronimo.ews.ws4j2ee.utils.packager.Packager" task from
> > the command line which further reinforces this notion of mine.
> > 
> > -- dims
> > 
> > -- 
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> > 
> 

Re: Commons Logging problem?

[Davanum Srinivas]

No problem at all, on the upside, ews cvs/build now uses the same
commons-logging that geronimo does AND there are a whole bunch of
printStackTrace and log.error to make it easy the next time Axis/EWS
breaks something :)

-- dims


On Thu, 4 Nov 2004 07:43:57 -0500 (EST), Aaron Mulder
<[EMAIL PROTECTED]> wrote:
> Believe it or not, it looks like only the first JAR in the
> dependency list is getting onto the classpath.  When I put a little
> wrapper JAR there first, none of the EWS stuff could be loaded.  If I take
> that away, EWS is first and Logging can't be loaded.  I need to figure out
> WTF is going on with this environment.  Sorry for taking so much of your
> time on it!
> 
> Aaron
> 
> 
> 
> On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> > Aaron,
> >
> > Here's my paste: http://rafb.net/paste/results/I89rnj81.html. If you
> > look closely, there's some problem loading commons logging stuff in
> > your environment.
> >
> > 24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
> > 25:   [java] [DEBUG] Class org.apache.commons.logging.LogFactory
> > loaded from ant loader
> > 26:   [java] [DEBUG] Class java.security.PrivilegedAction loaded from
> > parent loader
> > 27:   [java] [DEBUG] Finding class
> > org.apache.commons.logging.LogConfigurationException
> >
> > On my line 25: maven/ant is able to load the
> > org.apache.commons.logging.LogFactory class.
> >
> > 24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
> > 25:   [java] [ERROR] java.lang.NoClassDefFoundError
> > 26:   [ant] [DEBUG]  +User task: propertyfile
> > org.apache.tools.ant.taskdefs.optional.PropertyFile
> > 27:   [ant] [DEBUG]  +User task: vsscheckin
> > org.apache.tools.ant.taskdefs.optional.vss.MSVSSCHECKIN
> >
> > while on your line 25 (http://rafb.net/paste/results/I89rnj81.html)
> > there's a java.lang.NoClassDefFoundError...so i believe you have a
> > rogus commons-logging somewhere that is causing this problem. As you
> > mentioed you don't have a problem running the
> > "org.apache.geronimo.ews.ws4j2ee.utils.packager.Packager" task from
> > the command line which further reinforces this notion of mine.
> >
> > -- dims
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Commons Logging problem?

[Aaron Mulder]

Believe it or not, it looks like only the first JAR in the
dependency list is getting onto the classpath.  When I put a little
wrapper JAR there first, none of the EWS stuff could be loaded.  If I take
that away, EWS is first and Logging can't be loaded.  I need to figure out
WTF is going on with this environment.  Sorry for taking so much of your
time on it!

Aaron

On Thu, 4 Nov 2004, Davanum Srinivas wrote:
> Aaron,
> 
> Here's my paste: http://rafb.net/paste/results/I89rnj81.html. If you
> look closely, there's some problem loading commons logging stuff in
> your environment.
> 
> 24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
> 25:   [java] [DEBUG] Class org.apache.commons.logging.LogFactory
> loaded from ant loader
> 26:   [java] [DEBUG] Class java.security.PrivilegedAction loaded from
> parent loader
> 27:   [java] [DEBUG] Finding class
> org.apache.commons.logging.LogConfigurationException
> 
> On my line 25: maven/ant is able to load the
> org.apache.commons.logging.LogFactory class.
> 
> 24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
> 25:   [java] [ERROR] java.lang.NoClassDefFoundError
> 26:   [ant] [DEBUG]  +User task: propertyfile
> org.apache.tools.ant.taskdefs.optional.PropertyFile
> 27:   [ant] [DEBUG]  +User task: vsscheckin
> org.apache.tools.ant.taskdefs.optional.vss.MSVSSCHECKIN
> 
> while on your line 25 (http://rafb.net/paste/results/I89rnj81.html)
> there's a java.lang.NoClassDefFoundError...so i believe you have a
> rogus commons-logging somewhere that is causing this problem. As you
> mentioed you don't have a problem running the
> "org.apache.geronimo.ews.ws4j2ee.utils.packager.Packager" task from
> the command line which further reinforces this notion of mine.
> 
> -- dims
> 
> -- 
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 

Commons Logging problem?

[Davanum Srinivas]

Aaron,

Here's my paste: http://rafb.net/paste/results/I89rnj81.html. If you
look closely, there's some problem loading commons logging stuff in
your environment.

24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
25:   [java] [DEBUG] Class org.apache.commons.logging.LogFactory
loaded from ant loader
26:   [java] [DEBUG] Class java.security.PrivilegedAction loaded from
parent loader
27:   [java] [DEBUG] Finding class
org.apache.commons.logging.LogConfigurationException

On my line 25: maven/ant is able to load the
org.apache.commons.logging.LogFactory class.

24:   [java] [DEBUG] Finding class org.apache.commons.logging.LogFactory
25:   [java] [ERROR] java.lang.NoClassDefFoundError
26:   [ant] [DEBUG]  +User task: propertyfile
org.apache.tools.ant.taskdefs.optional.PropertyFile
27:   [ant] [DEBUG]  +User task: vsscheckin
org.apache.tools.ant.taskdefs.optional.vss.MSVSSCHECKIN

while on your line 25 (http://rafb.net/paste/results/I89rnj81.html)
there's a java.lang.NoClassDefFoundError...so i believe you have a
rogus commons-logging somewhere that is causing this problem. As you
mentioed you don't have a problem running the
"org.apache.geronimo.ews.ws4j2ee.utils.packager.Packager" task from
the command line which further reinforces this notion of mine.

-- dims

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: [VOTE] M3 pre ApacheCon

[Gianny Damour]

+1
Gianny
On 4/11/2004 3:48 AM, Jeremy Boynes wrote:
On the belief we need to formally vote on making a release, should we 
produce a M3 release?

[jira] Assigned: (GERONIMO-432) Dynamic gbean attributes don't have type information

[David Jencks (JIRA)]

 [ http://nagoya.apache.org/jira/browse/GERONIMO-432?page=history ]

David Jencks reassigned GERONIMO-432:
-

Assign To: David Jencks

> Dynamic gbean attributes don't have type information
> 
>
>  Key: GERONIMO-432
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-432
>  Project: Apache Geronimo
> Type: Bug
>   Components: kernel
> Versions: 1.0-M2
> Reporter: David Jencks
> Assignee: David Jencks
>  Fix For: 1.0-M3

>
> There isn't any way to give a dynamic gbean attribute a type.  This causes 
> problems when the attribute is of a primitive type: if no value is supplied, 
> null is pushed in, which gives a NPE from cglib when it tries to convert to a 
> primitive value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-432) Dynamic gbean attributes don't have type information

[David Jencks (JIRA)]

 [ http://nagoya.apache.org/jira/browse/GERONIMO-432?page=history ]
 
David Jencks closed GERONIMO-432:
-

 Resolution: Fixed
Fix Version: 1.0-M3

Fixed, and used for Activation specs and resource adapters/managed connection 
factories.

> Dynamic gbean attributes don't have type information
> 
>
>  Key: GERONIMO-432
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-432
>  Project: Apache Geronimo
> Type: Bug
>   Components: kernel
> Versions: 1.0-M2
> Reporter: David Jencks
>  Fix For: 1.0-M3

>
> There isn't any way to give a dynamic gbean attribute a type.  This causes 
> problems when the attribute is of a primitive type: if no value is supplied, 
> null is pushed in, which gives a NPE from cglib when it tries to convert to a 
> primitive value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Re: Axis module review

[Srinath Perera]

Thanks David :)  I am listing what might helpful for you to review.
(no hurry . even I like to have about two weeks time to get the
real thing started).

1) new code has removed alll the hardcoded obj names. 
2)At the test cases I do manually initaite the GBeans that would
started by the plan  in real case.
3) I think I got the basic of the plans. It is XML file explans the
set of GBeans and there referances. . If I need GBean A referd by
GBean B I should specify poth GBeans at the plan and put a referance
in B to A's obj name. then the B will get a refrance to A.
4) WSConFig Builder .. (it does not implement the interface properly
yet) build a GBean (s) for the WS, Store the GBeans in a confguration
and write the configuration to a store.  Using the URI return anyone
can load the configuration.
5) I am not sure How the Axis GBean should find the deployed
Configurations. I look at the referance patterns  but do not get the
real hang on it yet.
Cheers 
Srinath


On Wed, 3 Nov 2004 20:50:39 -0800, David Jencks <[EMAIL PROTECTED]> wrote:
> I am looking forward to looking at the new code very much and hope that
> I can quickly finish up what I've been working on so I can concentrate
> on the new code properly.
> 
> Many thanks,
> 
> david jencks
> 
> 
> 
> On Nov 3, 2004, at 8:39 PM, Srinath Perera wrote:
> 
> > Hi All;
> >
> > As I promise I have send a patch that fix the basic problems
> > (hardcoded obj names ..ect ) in the Axis geronimo module and get the
> > POJO case up and runing :).
> >
> > The patch is checked  in; I am looking foward to the comments to know
> > am I heading in the right direction. (I am busy with a exam and might
> > not write codes for about two weeks on the module.) but I will be
> > online and will happy if I can communicate in the mean time and
> > understand the expectation of the EWS from the Geronimo point of view
> > throughly.
> >
> > Thanks
> > Srinath
> >
> >
> >
> > On Fri, 29 Oct 2004 15:17:14 +0600, Srinath Perera
> > <[EMAIL PROTECTED]> wrote:
> >> Thanks everybody for the help :) :)... I think I got the big picure
> >> and hopfully should be able to get the Web Services working(which do
> >> not have EJB) behind them with out kernel. (There is a classloader
> >> issue when the EJB involved. I will try to get the code up removing
> >> all referances to kernel for POJO based WS.)
> >>
> >> I think over all the stuff over the weekend get back. My view about
> >> the Web Service is follows. There are two types of web services
> >> A) EJB based
> >> B) POJO based (servlet based one .. actually both has a servlet at the
> >> front so I dont see any sense in the name "Servlet based" : ) )
> >>
> >> Web Service(HTTP one we concern about) is a Servlet that accepts SOAP
> >> over HTTP. Axis basically
> >> 1) get the request XML (SOAP) and converts them to the java objects
> >> 2) call the java class (POJO) or EJB that provide the implementation
> >> 3) get what ever the result and send them back as SOAP
> >>
> >> Only deferance between the EJB based and  POJO based one is
> >> 1) Axis call a EJB instead of POJO at step #2
> >> 2) We have to make sure EJB is up when the webservice is called
> >>
> >> I think we should be able to do it with one WSBuilder. To be the steps
> >> is like follows
> >> 1. Geronimo Deployer find that the WAR/EAR is a ws module by looking
> >> at exsistance of the webservices.xml file in the module
> >> 2. The WSBuilder will create the confiuration and start it
> >> a. there should be a one GBean for each WS (we have to sort out
> >> how to do this)
> >> b. there should be a GBean for each EJB that referanced
> >> 3. when the confiuration started web services are avalible
> >>
> >> AxisGBean will keep track of the things and manage Axis
> >>
> >> Thanks
> >> Srinath
> >>
> >>
> >>
> >>
> >> On Fri, 29 Oct 2004 01:24:19 -0700, David Blevins
> >> <[EMAIL PROTECTED]> wrote:
> >>>
> >>> On Oct 28, 2004, at 11:52 PM, David Jencks wrote:
> >>>
>  My understanding of web services is that messages can be sent to
>  either servlets or ejbs.  (Apparently the servlets aren't "Servlet"
>  implementations, but are usually wrapped in one).  We need a gbean
>  to
>  be deployed for each such servlet and each such ejb.  At the moment
>  I
>  think the best approach is to have a WSServletBuilder and a
>  WSEJBBuilder that will actually build the gbeans.  These, especially
>  the WSEJBBuilder, would be similar to the openejb
>  SessionConfigBuilder.
> >>>
> >>> Not just similar to but the same as--one session bean can have all of
> >>> the following interfaces:
> >>>- Local
> >>>- Remote
> >>>- ServiceEndpoint
> >>>
> >>> All of which can have transaction attributes associated with them.
> >>> The
> >>> ServiceEndpoint interface can even be invoked directly by EJBs,
> >>> Servlets, or App Clients through declaring it as a service-ref and
> >>> looking a it up through JNDI.  Any invocations on the ServiceE

[jira] Commented: (GERONIMO-334) cannot find tools.jar at server startup

[John Sisson (JIRA)]

 [ 
http://nagoya.apache.org/jira/browse/GERONIMO-334?page=comments#action_55022 ]
 
John Sisson commented on GERONIMO-334:
--

I noticed that the following issue has a patch to use the eclipse compiler for 
Jetty:

http://nagoya.apache.org/jira/browse/GERONIMO-414

Could the eclipse compiler also be used to get around the ToolsJarHack that is 
used by:


/geronimo/modules/system/src/java/org/apache/geronimo/system/main/Daemon.java

/openejb/modules/core/src/java/org/openejb/config/NovaAssembler.java



> cannot find tools.jar at server startup
> ---
>
>  Key: GERONIMO-334
>  URL: http://nagoya.apache.org/jira/browse/GERONIMO-334
>  Project: Apache Geronimo
> Type: Bug
> Versions: 1.0-M2
>  Environment: red hat linux 9, kernel 2.4.2
> Reporter: karan singh malhi
> Priority: Trivial

>
> At server startup, i get a warning that tools.jar not found under 
> JAVA_HOME/lib. My tools.jar is both under JAVA_HOME/lib as well as under 
> JAVA_HOME/lib/ext.  Why cant it find it. Please see the trace below:- 
> [EMAIL PROTECTED] geronimo-1.0-M2]$ java -jar bin/server.jar 
> your/domain/name/Example
> 21:02:04,037 WARN  [ToolsJarHack] Could not all find java compiler: tools.jar 
> file not found at /usr/local/share/install/j2sdk1.4.2_04/jre/lib/tools.jar
> 21:02:04,045 INFO  [Daemon] Server startup begun
> 21:02:04,827 INFO  [Kernel] Starting boot
> 21:02:05,113 INFO  [MBeanServerFactory] Created MBeanServer with ID: 
> 1db7df8:ff4cdbab1a:-8000:j2ee:1
> 21:02:05,316 INFO  [Kernel] Booted
> 21:02:05,432 INFO  [ConfigurationManagerImpl] Loaded Configuration 
> geronimo.config:name="org/apache/geronimo/System"
> 21:02:06,088 INFO  [Configuration] Started configuration 
> org/apache/geronimo/System
> 21:02:06,152 INFO  [RMIRegistryService] Started RMI Registry on port 1099
> 21:02:06,233 INFO  [ReadOnlyRepository] Repository root is 
> file:/home/karan/geronimo-1.0-M2/repository/
> 21:02:06,304 INFO  [ConfigurationManagerImpl] Loaded Configuration 
> geronimo.config:name="your/domain/name/Example"
> 21:02:06,338 INFO  [ConfigurationManagerImpl] Loaded Configuration 
> geronimo.config:name="org/apache/geronimo/Server"
> 21:02:12,054 INFO  [Configuration] Started configuration 
> org/apache/geronimo/Server
> 21:02:13,166 INFO  [Configuration] Started configuration 
> your/domain/name/Example
> 21:02:14,214 INFO  [LoginService] Login server has been started
> 21:02:14,241 INFO  [ThreadPool] Thread pool DefaultThreadPool started
> 21:02:14,279 INFO  [SecurityServiceMBean] Security service started
> 21:02:14,284 INFO  [HttpServer] Starting Jetty/5.0.RC0
> 21:02:14,293 INFO  [HttpServer] Started [EMAIL PROTECTED]
> 21:02:14,307 INFO  [SocketListener] Started SocketListener on 0.0.0.0:8080
> 21:02:16,210 INFO  [HOWLLog] Initiating transaction manager recovery
> 21:02:17,158 INFO  [HOWLLog] In doubt transactions recovered from log
> 21:02:17,252 INFO  [PropertiesFileSecurityRealm] Properties File Realm - 
> geronimo-properties-realm - refresh
> 21:02:17,253 INFO  [PropertiesFileSecurityRealm] Properties File Realm - 
> geronimo-properties-realm - started
> 21:02:17,414 INFO  [Credential] Checking Resource aliases
> 21:02:19,469 INFO  [HttpContext] Started 
> WebApplicationContext[/test,file:/home/karan/geronimo-1.0-M2/config-store/10/war/]
> 21:02:19,663 INFO  [JettyWebAppContext] JettyWebAppContext started
> 21:02:19,950 INFO  [RMIConnectorServer] RMIConnectorServer started at: 
> service:jmx:rmi://localhost/jndi/rmi:/JMXConnector
> 21:02:19,952 INFO  [server:name=localhost,role=JMXService] Started 
> JMXConnector service:jmx:rmi://localhost/jndi/rmi:/JMXConnector
> 21:02:19,957 INFO  [Daemon] Server startup completed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-432) Dynamic gbean attributes don't have type information

[David Jencks (JIRA)]

Dynamic gbean attributes don't have type information


 Key: GERONIMO-432
 URL: http://nagoya.apache.org/jira/browse/GERONIMO-432
 Project: Apache Geronimo
Type: Bug
  Components: kernel  
Versions: 1.0-M2
Reporter: David Jencks


There isn't any way to give a dynamic gbean attribute a type.  This causes 
problems when the attribute is of a primitive type: if no value is supplied, 
null is pushed in, which gives a NPE from cglib when it tries to convert to a 
primitive value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Re: Axis module review

[David Jencks]

I am looking forward to looking at the new code very much and hope that 
I can quickly finish up what I've been working on so I can concentrate 
on the new code properly.

Many thanks,
david jencks
On Nov 3, 2004, at 8:39 PM, Srinath Perera wrote:
Hi All;
As I promise I have send a patch that fix the basic problems
(hardcoded obj names ..ect ) in the Axis geronimo module and get the
POJO case up and runing :).
The patch is checked  in; I am looking foward to the comments to know
am I heading in the right direction. (I am busy with a exam and might
not write codes for about two weeks on the module.) but I will be
online and will happy if I can communicate in the mean time and
understand the expectation of the EWS from the Geronimo point of view
throughly.
Thanks
Srinath

On Fri, 29 Oct 2004 15:17:14 +0600, Srinath Perera 
<[EMAIL PROTECTED]> wrote:
Thanks everybody for the help :) :)... I think I got the big picure
and hopfully should be able to get the Web Services working(which do
not have EJB) behind them with out kernel. (There is a classloader
issue when the EJB involved. I will try to get the code up removing
all referances to kernel for POJO based WS.)
I think over all the stuff over the weekend get back. My view about
the Web Service is follows. There are two types of web services
A) EJB based
B) POJO based (servlet based one .. actually both has a servlet at the
front so I dont see any sense in the name "Servlet based" : ) )
Web Service(HTTP one we concern about) is a Servlet that accepts SOAP
over HTTP. Axis basically
1) get the request XML (SOAP) and converts them to the java objects
2) call the java class (POJO) or EJB that provide the implementation
3) get what ever the result and send them back as SOAP
Only deferance between the EJB based and  POJO based one is
1) Axis call a EJB instead of POJO at step #2
2) We have to make sure EJB is up when the webservice is called
I think we should be able to do it with one WSBuilder. To be the steps
is like follows
1. Geronimo Deployer find that the WAR/EAR is a ws module by looking
at exsistance of the webservices.xml file in the module
2. The WSBuilder will create the confiuration and start it
a. there should be a one GBean for each WS (we have to sort out
how to do this)
b. there should be a GBean for each EJB that referanced
3. when the confiuration started web services are avalible
AxisGBean will keep track of the things and manage Axis
Thanks
Srinath

On Fri, 29 Oct 2004 01:24:19 -0700, David Blevins 
<[EMAIL PROTECTED]> wrote:
On Oct 28, 2004, at 11:52 PM, David Jencks wrote:
My understanding of web services is that messages can be sent to
either servlets or ejbs.  (Apparently the servlets aren't "Servlet"
implementations, but are usually wrapped in one).  We need a gbean 
to
be deployed for each such servlet and each such ejb.  At the moment 
I
think the best approach is to have a WSServletBuilder and a
WSEJBBuilder that will actually build the gbeans.  These, especially
the WSEJBBuilder, would be similar to the openejb
SessionConfigBuilder.
Not just similar to but the same as--one session bean can have all of
the following interfaces:
   - Local
   - Remote
   - ServiceEndpoint
All of which can have transaction attributes associated with them.  
The
ServiceEndpoint interface can even be invoked directly by EJBs,
Servlets, or App Clients through declaring it as a service-ref and
looking a it up through JNDI.  Any invocations on the ServiceEndpoint
interface go through JAX-RPC.

Aside from JAX-RPC/ServiceEndpoint invocations, people can invoke the
session bean through SOAP/WSDL over HTTP or HTTPS.  In this case 
there
is a mapping from WSDL to the ServiceEndpoint interface.

All in all, this is not very different from the CORBA integration 
which
also supports Java and non-Java clients through IIOP.  In this case 
we
use SOAP instead of IIOP,  ServiceEndpoint/JAX-RPC instead of
Remote/RMI-IIOP, WSDL-to-Java mapping instead of IDL-to-Java mapping,
and Axis instead of an ORB.

-David

Re: Axis module review

[Srinath Perera]

Hi All; 

As I promise I have send a patch that fix the basic problems
(hardcoded obj names ..ect ) in the Axis geronimo module and get the
POJO case up and runing :).

The patch is checked  in; I am looking foward to the comments to know
am I heading in the right direction. (I am busy with a exam and might
not write codes for about two weeks on the module.) but I will be
online and will happy if I can communicate in the mean time and
understand the expectation of the EWS from the Geronimo point of view
throughly.

Thanks
Srinath



On Fri, 29 Oct 2004 15:17:14 +0600, Srinath Perera <[EMAIL PROTECTED]> wrote:
> Thanks everybody for the help :) :)... I think I got the big picure
> and hopfully should be able to get the Web Services working(which do
> not have EJB) behind them with out kernel. (There is a classloader
> issue when the EJB involved. I will try to get the code up removing
> all referances to kernel for POJO based WS.)
> 
> I think over all the stuff over the weekend get back. My view about
> the Web Service is follows. There are two types of web services
> A) EJB based
> B) POJO based (servlet based one .. actually both has a servlet at the
> front so I dont see any sense in the name "Servlet based" : ) )
> 
> Web Service(HTTP one we concern about) is a Servlet that accepts SOAP
> over HTTP. Axis basically
> 1) get the request XML (SOAP) and converts them to the java objects
> 2) call the java class (POJO) or EJB that provide the implementation
> 3) get what ever the result and send them back as SOAP
> 
> Only deferance between the EJB based and  POJO based one is
> 1) Axis call a EJB instead of POJO at step #2
> 2) We have to make sure EJB is up when the webservice is called
> 
> I think we should be able to do it with one WSBuilder. To be the steps
> is like follows
> 1. Geronimo Deployer find that the WAR/EAR is a ws module by looking
> at exsistance of the webservices.xml file in the module
> 2. The WSBuilder will create the confiuration and start it
> a. there should be a one GBean for each WS (we have to sort out
> how to do this)
> b. there should be a GBean for each EJB that referanced
> 3. when the confiuration started web services are avalible
> 
> AxisGBean will keep track of the things and manage Axis
> 
> Thanks
> Srinath
> 
> 
> 
> 
> On Fri, 29 Oct 2004 01:24:19 -0700, David Blevins <[EMAIL PROTECTED]> wrote:
> >
> > On Oct 28, 2004, at 11:52 PM, David Jencks wrote:
> >
> > > My understanding of web services is that messages can be sent to
> > > either servlets or ejbs.  (Apparently the servlets aren't "Servlet"
> > > implementations, but are usually wrapped in one).  We need a gbean to
> > > be deployed for each such servlet and each such ejb.  At the moment I
> > > think the best approach is to have a WSServletBuilder and a
> > > WSEJBBuilder that will actually build the gbeans.  These, especially
> > > the WSEJBBuilder, would be similar to the openejb
> > > SessionConfigBuilder.
> >
> > Not just similar to but the same as--one session bean can have all of
> > the following interfaces:
> >- Local
> >- Remote
> >- ServiceEndpoint
> >
> > All of which can have transaction attributes associated with them.  The
> > ServiceEndpoint interface can even be invoked directly by EJBs,
> > Servlets, or App Clients through declaring it as a service-ref and
> > looking a it up through JNDI.  Any invocations on the ServiceEndpoint
> > interface go through JAX-RPC.
> >
> > Aside from JAX-RPC/ServiceEndpoint invocations, people can invoke the
> > session bean through SOAP/WSDL over HTTP or HTTPS.  In this case there
> > is a mapping from WSDL to the ServiceEndpoint interface.
> >
> > All in all, this is not very different from the CORBA integration which
> > also supports Java and non-Java clients through IIOP.  In this case we
> > use SOAP instead of IIOP,  ServiceEndpoint/JAX-RPC instead of
> > Remote/RMI-IIOP, WSDL-to-Java mapping instead of IDL-to-Java mapping,
> > and Axis instead of an ORB.
> >
> > -David
> >
> >
>