Re: DO NOT REPLY [Bug 30548] - NPE in oata.Project when executing emma task from netbeans.

2005-05-29 Thread Thomas Schapitz
[EMAIL PROTECTED] schrieb:

>DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
>RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>.
>ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
>INSERTED IN THE BUG DATABASE.
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=30548
>
>
>
>
>
>--- Additional Comments From [EMAIL PROTECTED]  2005-05-29 12:25 ---
>I later on found out, that this had partly to do with the clean up code in the
>ant-bridge of NB 3.6.
>Looks like the ant-bridge is trying to prevent memory leaks by forcing some
>of the ANT-Internal variables to 'null' via reflection API.
>(Possible only, if there is no security manager, or security manager 
>permissions
>are set accordingly).
>So anyway, this isn't ANTs fault, but could be considered a blatand breach of 
>ANTs isolation by Netbeans...
>The problem vanished in NB 4.0.
>
>  
>
As an after thought:
NB resorting to a means like this might indicate, that integrating ANT into
another application has its difficulties with house keeping.

I'm not good at ANTs internals, and don't know if something alike is
already there, but maybee it would be of help for IDEs like NB, if there
was an explicitly defined lifecycle for all important ANT Objects, namely
Projects, Targets, and Tasks, including a cleanUp() method, releasing
internal resources.

Thomas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: ant/docs/manual/CoreTasks checksum.html

2005-02-17 Thread Thomas Schapitz
Kev Jackson schrieb:
I don't think that this is the major problem.  It's very very very 
unlikely that anyone would want to tamper with Ant (why bother, a user 
can always get teh source and build themselves?).  The problem is that 
when using Ant to build new code (and to generate a checksum for that 
distribution), now you as the developer of new-shiny-applictaion have 
to decide whether anyone is going to take the time to create a fake 
version of your app.  
Corruption of the new App isn't necessarily the intention of a potential 
attacker. It's far more interesting,
to intercept passwords passed into ftp, ssh, or scp tasks,  spying into 
the file system accessible
to the ant installation, or even to install malware.

This said, our options to prevent this are very limited, and depend 
heavily on the
cooperation of ANT users. Or did you ever knew somebody, who checked the
checksums of an ANT distribution contained as convienance in an other 
system
(e.g. netbeans, or weblogic)?

Thomas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Probable Bug (NPE) and Fix in class oata.Project?

2004-08-08 Thread Thomas Schapitz
Hi all,
When I'm using Ant 1.6.1 in Netbeans 3.6 to execute one of the emma-tasks
(see: emma.sourceforge.net), I'm seeing the following stacktrace:

instrument:
java.lang.NullPointerException
   at org.apache.tools.ant.Project.getThreadTask(Project.java:1985)
   at org.apache.tools.ant.Project.demuxFlush(Project.java:1155)
   at
org.apache.tools.ant.DemuxOutputStream.processFlush(DemuxOutputStream.java:186)
   at
org.apache.tools.ant.DemuxOutputStream.flush(DemuxOutputStream.java:211)
   at java.io.PrintStream.flush(PrintStream.java:136)
   at
sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:410)
   at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
   at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
   at java.io.BufferedWriter.flush(BufferedWriter.java:230)
   at java.io.PrintWriter.flush(PrintWriter.java:120)
   at com.vladium.logging.Logger.cleanup(Logger.java:436)
   at com.vladium.logging.Logger.pop(Logger.java:364)
   at com.vladium.emma.Processor.run(Processor.java:60)
   at com.vladium.emma.instr.instrTask.execute(instrTask.java:77)
   at com.vladium.emma.emmaTask.execute(emmaTask.java:57)
   at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269)
   at org.apache.tools.ant.Task.perform(Task.java:364)
   at org.apache.tools.ant.Target.execute(Target.java:301)
   at org.apache.tools.ant.Target.performTasks(Target.java:328)
   at org.apache.tools.ant.Project.executeTarget(Project.java:1215)
   at org.apache.tools.ant.Project.executeTargets(Project.java:1063)
   at
org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:178)
   at
org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:252)
   at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)
This seems to happen only in Netbeans, not when I'm calling ANT (1.6.0,
or 1.6.2)
from the commandline. (didn't try 1.6.1)
The relevant section in oata.Project is:
  /**
* Get the current task associated with a thread, if any
*
* @param thread the thread for which the task is required.
* @return the task which is currently registered for the given
thread or
* null if no task is registered.
*/
   public Task getThreadTask(Thread thread) {
   Task task = (Task) threadTasks.get(thread); <--- NPE occurs here.
   if (task == null) {
   ThreadGroup group = thread.getThreadGroup();
   while (task == null && group != null) {
   task = (Task) threadGroupTasks.get(group);
   group = group.getParent();
   }
   }
   return task;
   }
Fixing this to read.
   public Task getThreadTask(Thread thread) {
   Object task = threadTasks.get(thread);  // <-- removed cast
   if (task == null) {
   ThreadGroup group = thread.getThreadGroup();
   while (task == null && group != null) {
   task = (Task) threadGroupTasks.get(group);   // 
   group = group.getParent();
   }
   }
   return (Task) task;  // <-- inserted cast
   }
Solved the problem for me.
Looks to me, as if somebody was aware, that the threadTask.get() might
return null, but misplaced the cast to java.lang.Task.
As a side thought, I'm wondering, wether this might happen to
threadGroupTask.get() also, so it would be better to remove the cast
there also
Btw, I checked the most current source (1.7 alpha?) also, it seemed
to be unchanged in this respect, so a patch would be applicable for
all sources from 1.6.1 up to now, maybe even earlier.
Cheers!
Thomas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Probable Bug (NPE) and Fix in class oata.Project?

2004-08-07 Thread Thomas Schapitz
Hi all,
When I'm using Ant 1.6.1 in Netbeans 3.6 to execute one of the emma-tasks
(see: emma.sourceforge.net), I'm seeing the following stacktrace:

instrument:
java.lang.NullPointerException
   at org.apache.tools.ant.Project.getThreadTask(Project.java:1985)
   at org.apache.tools.ant.Project.demuxFlush(Project.java:1155)
   at 
org.apache.tools.ant.DemuxOutputStream.processFlush(DemuxOutputStream.java:186)
   at 
org.apache.tools.ant.DemuxOutputStream.flush(DemuxOutputStream.java:211)
   at java.io.PrintStream.flush(PrintStream.java:136)
   at 
sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:410)
   at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
   at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
   at java.io.BufferedWriter.flush(BufferedWriter.java:230)
   at java.io.PrintWriter.flush(PrintWriter.java:120)
   at com.vladium.logging.Logger.cleanup(Logger.java:436)
   at com.vladium.logging.Logger.pop(Logger.java:364)
   at com.vladium.emma.Processor.run(Processor.java:60)
   at com.vladium.emma.instr.instrTask.execute(instrTask.java:77)
   at com.vladium.emma.emmaTask.execute(emmaTask.java:57)
   at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269)
   at org.apache.tools.ant.Task.perform(Task.java:364)
   at org.apache.tools.ant.Target.execute(Target.java:301)
   at org.apache.tools.ant.Target.performTasks(Target.java:328)
   at org.apache.tools.ant.Project.executeTarget(Project.java:1215)
   at org.apache.tools.ant.Project.executeTargets(Project.java:1063)
   at 
org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:178)
   at 
org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:252)
   at 
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)

This seems to happen only in Netbeans, not when I'm calling ANT (1.6.0, 
or 1.6.2)
from the commandline. (didn't try 1.6.1)

The relevant section in oata.Project is:
  /**
* Get the current task associated with a thread, if any
*
* @param thread the thread for which the task is required.
* @return the task which is currently registered for the given 
thread or
* null if no task is registered.
*/
   public Task getThreadTask(Thread thread) {
   Task task = (Task) threadTasks.get(thread); <--- NPE occurs here.
   if (task == null) {
   ThreadGroup group = thread.getThreadGroup();
   while (task == null && group != null) {
   task = (Task) threadGroupTasks.get(group);
   group = group.getParent();
   }
   }
   return task;
   }

Fixing this to read.
   public Task getThreadTask(Thread thread) {
   Object task = threadTasks.get(thread);  // removed cast
   if (task == null) {
   ThreadGroup group = thread.getThreadGroup();
   while (task == null && group != null) {
   task = (Task) threadGroupTasks.get(group);
   group = group.getParent();
   }
   }
   return (Task) task;
   }
Solved the problem for me.
Looks to me, as if somebody was aware, that the threadTask.get() might 
return null,
but misplaced the cast to java.lang.Task.

As a side thought, I'm wondering, wether this might happen to
threadGroupTask.get() also, so it would be better to remove the cast 
there also

Cheers!
Thomas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: BugID 27282 Misspelling: s/occured/occurred/g

2004-02-28 Thread Thomas Schapitz
Not a native speaker either, but in possesion of an Oxford Advanced 
Learners Dictonary...

This states:
occur:  take place; happen: Don't let this ~ again
... An idea has ~red to me. ...
Since it usally lists differences for GB/UK, and doesn't mention
it here,
 'occurred'
is probably the only correct spelling for this one.
Regards,
Thomas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: FYI: Blog "Complex build systems need a real language" found

2004-01-22 Thread Thomas Schapitz
Oh mirror, please tell me, who in the world has the most complicated 
build script?

In the comments regarding the article I found one crucial hint that I want
to emphasize:
Big Projects usually have two sorts of dependencies, that need build
managing:
A vertical one, according to the software architecture choosen,
and a horizontal one, according to the decomposition of large
systems in business subsystems of manageable size.
As I take it, the overly large build file is partly due to the fact, 
that they failed
to recognize this, i. e. by decomposing the build file int two ortogonal 
ones.

In a moderately complex architecture, you should get away with 20 to 30 
targets,
all containig at most one major task involving mapping.
Because the architecture should be the same for all the business 
components, whats
left, is defining a DAG (either in ANT or any other tool) invoking the 
ANT-Skript
covering the architectural aspects.

Treating every system separately in the same file,
would get you quickly into the range of  100dreds of
targets, which could easily explain the outrages build file size.
In a certain way, I'm percieving ANT scripts as an static picture of the 
systems
architecture. (Maybe that is why feel, that dynamic skripting ins't 
needed there
- I like the rather declarative approach of ANT)

But, speaking of something else...
misstakes like this might be partly due to a lack of  'ANT Best Practices'.
Anybody thinking about including something about that into the 
documentation?

Regards
Thomas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]