Re: problem running or building JSP application after upgrade to 6.7

Re: JasperReportViewer plugin

Re: Off-topic: Sun applet life-cycle implementation bug in Linux?

Re: Badly formed Maven project in 6.7?

Fabrizio Giudici wrote:
> Andrew Chandler wrote:
>> I'd be willing to bet that netbeans updgraded to the newish maven 
>> syntax that requires a property to get set for the local or codepage 
>> or some such thing - we ran into that with hudson and regular maven 
>> itself about 6 months ago.  I'm not seeing the problem you mention 
>> but I can definately picture it being the culprit if nothing changed 
>> about the POM file.
>>
> http://www.netbeans.org/issues/show_bug.cgi?id=167919
>
> For the record, I see in the tooltip: "Missing extensions or plugin 
> with extension."
>
> I have an extension in the pom, but being relatively new to Maven I 
> don't understand where the problem is. In any case, even if it turned 
> out we're missing something in our pom, since the projects in the end 
> build, the "Badly formed..." message is exaggerated, and eventually 
> should be a warning.

no sorry, it's not "exaggerated". The maven embedder fails to load the 
project, failing to return a MavenProject instance and instead throwing 
an exception. Therefore I have nothing to work with.
The message can appear for valid reasons on the user side (like you've 
broken your pom's XML) or for reasons on the embedder code side (a bug 
in the embedder). for 6.7 I've fixed a number of bugs in the embedder 
and significantly reduced the likelyhood of this happening. I'll take a 
look what the problem is here.

Milos
>
>
> -- 
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
> Fabrizio.Giudici <at> tidalwave.it - mobile: +39 348.150.6941
>   

Re: Off-topic: Sun applet life-cycle implementation bug in Linux?

Thanks Melongo. The two pieces of information I didn't know until 
reading your post and then doing a quick google to
http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html
was that (1) applets are nothing more than threads started by the 
browser.  I always thought that the browser just started some kind of 
manager (the plugin) which then started the applet threads as needed.  
So I thought that the plugin could set thread priority since it manages 
them (and, thus, maybe affect the scheduling by the native OS).  (2) I 
didn't know that the applet management changed in 1.6_10.  There was an 
interesting bit about shared class loaders among the applet instances 
and how to turn this off...I will need this since the problem I 
described is due to some static variable suddenly being shared among 
applet instances when before 1.6_10 they apparently weren't.

Thx again.
tom

On 06/30/2009 10:46 PM, Melongo Annabel wrote:
> Thomas,
> The threads might be spawned by the JVM but they aren't processed by 
> it rather by the OS. Each OS has its own way of handling 
> multi-threaded applications. Some will use time-slicing ( also known 
> as Round Robin ) and some will use preemptive scheduling. In the 
> time-slicing mechanism, which Windows I think uses, each thread is 
> giving a chunk of time of execution. In the preemptive scheduling 
> mechanism, the highest priority thread executes first and the lowest 
> later.
> Now let's see how this translates in your issue:
>
> Time-slicing: When the user clicks the reload button on an existing 
> applet, the OS will give the existing applet a predefined time to stop 
> and then initialize the new thread ( the reloaded applet ) within the 
> same predefined time. That's why in windows, you see that the old 
> applet will exit and THEN a new applet is initialized.
>
> Preemptive scheduling: In this scenario when the user clicks on the 
> reload button, the existing applet is given a low priority and the new 
> applet ( the reload ) is given a highest one. That's why you observe 
> the behavior of the reloaded applet happening BEFORE the old applet is 
> destroyed in Linux.
>
> How the multi-threaded mechanism is performed has NOTHING to do with 
> NB or the JVM but rather  the OS on which the JVM is running. It's 
> this OS that ultimately processes the threads' execution.
>
> If this still isn't clear, here's a real life example. Let's say your 
> boss ( JVM ) wants to send two letters. It will use a carrier ( The OS 
> ) to achieve this.Now the carrier can be the state postal service 
> (USPS, for the United States ) or UPS. As far as the postal service 
> goes, the two letters regardless of their delivery status, if sent 
> within the USA will all get to their destination within 3 days ( 
> Time-slicing ). However, if UPS is used, then delivery status becomes 
> a determining factor. If the boss has a letter with Next Day Delivery 
> and another with regular delivery, then the Next Day Delivery letter 
> has the highest priority and will arrive ( be executed ) before the 
> lowest priority letter which in our case is the regular delivery 
> letter. Hope the example will clarify what's happening behind the 
> scene. Thanks.
>
> ------------------------------------------------------------------------
> *From:* Thomas Wolf <twolf <at> netforensics.com>
> *To:* nbusers <at> netbeans.org
> *Sent:* Tuesday, June 30, 2009 7:27:39 AM
> *Subject:* [nbusers] Off-topic: Sun applet life-cycle implementation 
> bug in Linux?
>
> Thanks for the reply, Melongo.  I'm not sure I agree with you on how 
> normal it is, though.  I don't find it normal at all that a Java 
> implementation - written by the same company - is different across 
> operating systems.  The starting of the applet threads seems to me 
> entirely in the JVM's control - why wouldn't it start/stop them in the 
> same order on all operating systems?  Makes it unnecessarily difficult 
> determining when a shared resource (e.g. a connection to the server) 
> can be cleaned up.
>
> Thnx for any insight.
> tom
>
>
> On 06/29/2009 10:20 PM, Melongo Annabel wrote:
> > Thomas,
> > I don't think it's a bug rather a NORMAL behavior. The system is 
> treating each applet has a thread. So when a reload is called, a new 
> thread is spawned and the old one is killed. Now depending on the OS, 
> the first thread is first killed THEN the second one is initialized 
> but on some other system, the behavior might be reversed. That might 
> be the case on Linux.
> >
> > ------------------------------------------------------------------------
> > *From:* Thomas Wolf <twolf <at> netforensics.com 
> <mailto:twolf <at> netforensics.com>>
> > *To:* nbusers <at> netbeans.org <mailto:nbusers <at> netbeans.org>
> > *Sent:* Monday, June 29, 2009 3:44:12 PM
> > *Subject:* [nbusers] Sun applet life-cycle implementation bug in Linux?
> >
> > I am debugging our product's applet and noticed that on Linux (but 
> not on Windows), the applet life-cycle seems f'ed up: When the applet 
> starts, its init() and then its start() is called....as expected.  If 
> the user hits "Reload" on the browser, a new applet is loaded, its 
> init() and start() are called AND THEN the stop() and destroy() are 
> called for the original applet.  The expected behavior (and found in 
> the Windows implementation) is for the first instance's stop/destroy 
> to be called before the 2nd instance's init()/start() are called.
> >
> > Has anyone come across this?  Seems like an obvious bug, no?
> >
> > Thnx,
> > tom
> >
> >
> > Java console showing the JDK and method calls:
> >
> > Java Plug-in 1.6.0_14
> > Using JRE version 1.6.0_14-b08 Java HotSpot(TM) Client VM
> > User home directory = /home/twolf
> > ----------------------------------------------------
> > c:  clear console window
> > f:  finalize objects on finalization queue
> > g:  garbage collect
> > h:  display this help message
> > l:  dump classloader list
> > m:  print memory usage
> > o:  trigger logging
> > p:  reload proxy configuration
> > q:  hide console
> > r:  reload policy configuration
> > s:  dump system and deployment properties
> > t:  dump thread list
> > v:  dump thread stack
> > x:  clear classloader cache
> > 0-5: set trace level to <n>
> > ----------------------------------------------------
> >
> >
> > init() For applet:1094d48
> > start() For applet:1094d48
> > init() For applet:883644
> > start() For applet:883644
> > stop() For applet:1094d48
> > destroy() For applet:1094d48
> >
> >
>

Re: Badly formed Maven project in 6.7?

Andrew Chandler wrote:
> I'd be willing to bet that netbeans updgraded to the newish maven 
> syntax that requires a property to get set for the local or codepage 
> or some such thing - we ran into that with hudson and regular maven 
> itself about 6 months ago.  I'm not seeing the problem you mention but 
> I can definately picture it being the culprit if nothing changed about 
> the POM file.

no, actually our maven embedder is a snapshot of maven sources trunk 
from July 2008, it appeared in the same form in 6.5, except for some 
additional bugfixes from my side.
http://hg.netbeans.org/main/file/49d8672cc9a6/maven.embedder/external/maven-embedder-patching.txt

the problems seen can be caused by some other bugs or incompatibilities 
in the embedder, by network problems with remote repositories, 
concurrency in local repository, OR it can be a problem in the project. 
I cannot really comment more specificly without seeing the project in 
question though.

Some of the most common issues (which are linked from the Show/Resolve 
problems action/dialog) are described here:
http://wiki.netbeans.org/MavenBadlyFormedProjectErrors

Milos

>
>
> On Tue, 2009-06-30 at 10:33 +0200, mkleint wrote:
>> you can try reloading the project (from project node's popup), the Show 
>> problems action in the popup shall have more information about the failure.
>>
>> Milos
>>
>> Cush1978 wrote:
>> > Hi all,
>> >
>> >
>> >
>> > I've run NetBeans 6.5 with all the current patches (which I guess makes it 6.5.1) with Maven projects
without issue.
>> >
>> >
>> >
>> > Today I downloaded 6.7 and the same Maven projects are considered "Badly Formed".  They build/run just
fine.  There are no offending lines marked in the pom.xml or the settings.xml file.  I've indexed the
repositories and all, but these projects simply will not stop being "Badly formed".  Anyone else seen a
similar issue?
>> >
>> >
>> >
>> >
>> >   
>>
>>
>>     
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 
a

Re: Copy on Save functionality

Andrew Chandler wrote:
> Does this  mean if I grab the most recent nightly build there's a shot 
> that this might work even in the complicated scenario I described?
>
I hope so.
>
> Keep in mind in the picture below I am deploying or running or 
> debugging the ear, but the updated html/javascript/css is in one of 
> the war projects the ear depends on (all projects are open 
> simultaneously in netbeans btw)
>
I think that should work as AFAIK the server integration will use the 
expanded folders for the web apps. #157093 only affects changes in "jar" 
dependencies within wars.

If your scenario doesn't work in latest dev builds, please file an 
issue. Thanks.

Milos

>
>
> On Tue, 2009-06-30 at 07:57 +0200, mkleint wrote:
>> in 6.7 copying of resources (on-save, rather then before-run) only 
>> worked for war packaging projects.
>> in 6.8 it should perform a true copy-on-save for all resources for all 
>> packagings.
>> http://www.netbeans.org/issues/show_bug.cgi?id=148499
>>
>> possibly this one is also related, 
>> http://www.netbeans.org/issues/show_bug.cgi?id=157093 if jar within a 
>> war file is modified the jar file n expanded war is not updated.
>>
>> Milos
>>
>> Andrew Chandler wrote:
>> > Greetings - I'm hoping somebody knows how I can implement the 
>> > following.  
>> >
>> > First some bacground:
>> >
>> >
>> > Very large J2EE app composed of multiple WAR files/Jars
>> > Organized and built using Maven.
>> > Parent Pom
>> >        jar projects
>> >                 jar x
>> >                 jar y
>> >        war projects
>> >                 war a
>> >                 war b
>> >                  war c
>> >         ear project
>> >                  depends on others and gathers their targets, creates Ear
>> >
>> >
>> > Opening this in Netbeans works well, things compile etc
>> > Debugging netbeans works ok, we can attach to glassfish and even 
>> > hotswap code within reason.
>> >
>> >
>> > However for all the stuff in the various war's that is xhtml, 
>> > Javascript, or CSS the debug cycle stinks.  I suspect this is partly 
>> > because of the very complicated project structure but what I want to 
>> > do is register some sort of action for files of extension x y z in a 
>> > project to automatically try to copy it to a hard coded location as 
>> > its saved.  (It should be saved where it was opened from as well)  - 
>> > This way I can specify the directory where glassfish exploded the ear 
>> > to and the text files will get updated and a simple refresh in the 
>> > browser gets you an instant way to see the effect ....we currently do 
>> > this but we have to do the copy by hand and it truly is a pain.   Any 
>> > way to auto synchronize or get this behavior from netbeans?
>> >
>> > Thanks for the help in advance
>> >
>> > P.S.  I believe a straight web project with a war file automatically 
>> > does this in netbeans, its only because of the nested wars within an 
>> > ear I believe that we have an issue.
>> >
>> >
>> > -- 
>> > This message has been scanned for viruses and
>> > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>> > believed to be clean. 
>>
>>
>>     
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 

Re: Scala plugin with NetBeans 6.7 release?

http://sourceforge.net/project/showfiles.php?group_id=192439&package_id=256544

This seems to be the 6.7 version, and does not appear to be compatible  
with 6.5.1.

On 01/07/2009, at 8:23 AM, Louis Botterill wrote:

> Hi,
>
> I've been using the Scala plugin for NetBeans 6.5(.1) regularly,  
> will this work in the new 6.7 release? I can only see a version for  
> 6.5, but I'm not sure how compatible 6.5 is with 6.7?
>
> cheers, Louis
>
> -- 
> www.chillipower.com
> http://louisbotterill.blogspot.com/
>
> Please consider your environmental responsibility before printing  
> this e-mail
>

Editor: Is it possible to...

Enable somehting like "Hungry Backspace". That means pressing backspace
removes all empty spaces.
I really can't live without it.

Example:

    String s = "asdf"

            |

Pressing backspace once(!) results in

    String s = "asdf"
    |

Pressing backspace one more time results in:

    String s = "asdf"|

Any ideas? I really love that feature in IntelliJ and would like to use
in in Netbeans to.

Second: Is it possible to increase the selection based on the logical
structure of the code?

Example:

  if (true){	
    String s = "asdf"|.toLowerCase();
  }

Pressing the shortcut (Ctrl-W in IntelliJ) marks "asdf". Pressing it
further marks those parts:

"asdf"|.toLowerCase()
then
String s = "asdf"|.toLowerCase();
then
  if (true){	
    String s = "asdf"|.toLowerCase();
  }
then the method, the class, the file...

Regards,

Johannes

Running JAR from Netbeans IDE