[MAVEN_INCREMENTAL_BUILD-14] java.lang.IllegalStateException: basedir ........target\classes does not exist Created: 04/May/12  Updated: 04/May/12

Status: Open
Project: maven-incremental-build
Component/s: None
Affects Version/s: 1.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Javatar007 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: basedir, classes, empty, exception, missing, src


Seems to be caused by empty 'project/src' folder.
In our multimodule project there are some submodules for generating from wsdl. These have empty 'src' folder.
(I've replaced the long project path by '(...)' in the log below).

[INFO] Building XConnector
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [incremental-build:incremental-build

{execution: default}

[INFO] Verifying module descriptor ...
[INFO] Verifying parent modules...
[INFO] Verifying resources...
[INFO] Resources directory does not exist : C:(...)\res
[INFO] Verifying sources...
[INFO] No target directory, build is required.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] basedir C:(...)\target\classes does not exist
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.IllegalStateException: basedir C:(...)\classes does not exist
at org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:542)
at net.java.mavenincrementalbuild.IncrementalBuildMojo.directoryUpdated(IncrementalBuildMojo.java:259)
at net.java.mavenincrementalbuild.IncrementalBuildMojo.sourcesUpdated(IncrementalBuildMojo.java:306)
at net.java.mavenincrementalbuild.IncrementalBuildMojo.execute(IncrementalBuildMojo.java:135)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)

This exception is not thrown when using version 1.5.

[JAVASERVERFACES-3071] javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL doesn't work at all Created: 28/Oct/13  Updated: 04/Dec/14  Resolved: 14/Nov/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.4
Fix Version/s: 2.2.5

Type: Bug Priority: Major
Reporter: kithouna Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

GlassFish 4.0

Attachments: Zip Archive emptystring.zip    
Issue Links:
is related to JAVASERVERFACES_SPEC_PUBLIC-1203 Empty String as Null is not effective... Closed


javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL in web.xml doesn't work at all with Mojarra 2.2.1 and 2.2.4. I created a very basic test project and ran it on GlassFish with Mojarra 2.1.10 (changed EE version in POM to 6) and it works fine, but using 2.2.1 or 2.2.4 on GlassFish 4.0 (EE version changed to 7) the setter for a text input field is called with an empty string instead of null.

Comment by Manfred Riem [ 28/Oct/13 ]

Please send your reproducer to issues@javaserverfaces.java.net. Thanks!

Comment by Manfred Riem [ 29/Oct/13 ]

From email to issues@javaserverfaces.java.net


Just leave the input field empty and press the submit button.

Using Mojarra 2.2.4 I get:

Information: Constructed testcases.emptystring.TestBean@1007b020
Information: Getting string: null
Information: Setting string from null to
Information: Saving string:
Information: Getting string:

It should read (and does with Mojarra 2.1.10 on GF, EE versions in POM changed to 6):

Information: Constructed testcases.emptystring.TestBean@1007b020
Information: Getting string: null
Information: Setting string from null to null
Information: Saving string: null
Information: Getting string: null

Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! Rundum glücklich mit freenetMail

Comment by Manfred Riem [ 14/Nov/13 ]

It was determined this is an EL issue and the EL implementation has been fixed to fix this.

Comment by adrianosch [ 27/Feb/14 ]

Where can we find the updated EL impl artifact? I've been searching for it, but '3.0' is the latest version in maven central.

Comment by dbenegiamo [ 09/Apr/14 ]

Hi, Mojarra version 2.2.5 still have this issue. Mandred, could you kindly point to the proper fix? What we have to update instead of Mojarra?

Comment by rekiem87 [ 10/Apr/14 ]

Latest glassfish build (4.0.1) still have the issue, workaround finded in http://stackoverflow.com/questions/21880017/interpret-empty-string-submitted-values-as-null-not-working

Comment by codylerum [ 30/Jul/14 ]

This is a Wildfly 8.1.0.Final issue as well. Does anyone know which EL3 version or UEL issues fixes this?

Comment by codylerum [ 31/Jul/14 ]

This is fixed in EL org.glassfish:javax.el 3.0.1-b05 which is being pulled into wildfly 8.x

Comment by mauromol [ 03/Dec/14 ]

We are in December and javax.el 3.0.1-b05 is not yet available on Maven Central.
Also, the "Won't Fix" on UEL-13 is not encouraging...

Comment by Manfred Riem [ 03/Dec/14 ]

See http://repo1.maven.org/maven2/org/glassfish/javax.el/3.0.1-b05/ which has been available since 7 July 2014

Comment by mauromol [ 03/Dec/14 ]

Hmm... thank you, I was looking at javax.el:javax.el-api, which does not have version 3.0.1-b05.
Anyway, if I understand it correctly, there's nothing I can do with such a library update in my web application unless I change Tomcat's own JAR (also Tomcat 8 seems to suffer from this problem). Am I correct?

Comment by Manfred Riem [ 03/Dec/14 ]

Yes Tomcat would have to patch their EL

Comment by mauromol [ 03/Dec/14 ]

But I doubt they will ever do, since the did the opposite fix:
because of the EL specification has this requirement: EL_SPEC-18
I'm wondering what was fixed in Glassfish implementation: did they go against the specification?

Meanwhile, I really need some kind of workaround for my JSF environment. JAVASERVERFACES_SPEC_PUBLIC-1203 mentions an ELResolver... should I add it to my faces.config.xml inside <el-resolver>? I'm already using a SpringBeanFacesELResolver, does this interfere in some way? (I don't know how {{ELResolver}}s are chained...).
Sorry for asking here, but I already spent a lot of time to try to find out a solution: a converter doesn't do the trick, org.apache.el.parser.COERCE_TO_ZERO=false system property, which is suggested in some StackOverflow questions and blogs, doesn't work in Tomcat 8... I don't know what to do rather than post-process all my beans after a successful submission

Of course, javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is already set to true in web.xml...

Comment by Manfred Riem [ 03/Dec/14 ]

You will have to raise the issue in the EL_SPEC mailing list.

Yes you can add another ELResolver, but the ordering is dependent on your faces-config.xml and the other JARs included.

Comment by mauromol [ 04/Dec/14 ]

Just for the records, a new issue has been filed for Tomcat too, at least to give the chance to override this via a custom EL resolver.

[JAVAEETUTORIAL-83] Java Servlet Advanced Topics section is empty Created: 20/Apr/12  Updated: 11/Feb/13  Resolved: 11/Feb/13

Status: Closed
Project: javaeetutorial
Component/s: doc
Affects Version/s: 6.0.7-3
Fix Version/s: 6.0.8

Type: Bug Priority: Major
Reporter: rcervera Assignee: jendrock
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: empty, servlet


http://docs.oracle.com/javaee/6/tutorial/doc/glrbb.html is empty.

Comment by jendrock [ 25/Apr/12 ]

This chapter was not supposed to be included in the build. I need to include three viable topics, at least some of which can also include (or reference) an example, before I am willing to add this chapter into the tutorial. I could discuss such topics as asynchronous processing, absolute ordering of fragments in the web.xml file (not geared for our audience), dynamic registration of servlets, etc. I may add this in for the next respin, especially that we have a few rudimentary examples that we can use to show some of the aforementioned features.

Comment by jendrock [ 30/May/12 ]

Will create a chapter that addresses two features that may be of interest to our target audience: (1) file upload and (2) dynamic registration. Have a very simple example for (2) that demonstrates dynamic registration of a servlet that sets an initialization parameter. Will point back to Duke's Forest for file upload. The case study uses this feature when a user creates a new product and adds an image to the product description.

Comment by jendrock [ 11/Feb/13 ]

The chapter was completed and included in the documentation that went out with the 6.0.8 release.

For Java EE 7, the content has been folded back into the base Servlet chapter.

[JAI_IMAGEIO-22] jai-imageio does not read/write tiff-images Created: 29/Mar/14  Updated: 29/Mar/14

Status: Open
Project: jai-imageio
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tps800 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Linux test-jrodev12-muc.bfs.de 3.8.13-26.2.2.el6uek.x86_64 #2 SMP Tue Mar 25 18:51:35 PDT 2014 x86_64 x86_64 x86_64 GNU/Linux
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Tags: codec, empty, field-read-error, tiff


Tiff-files are stated to be empty, are not read or reading fails with an error message:

29.03.2014 18:20:19 (UTC):Loading file: /opt/kit/JRodosClientSeptember2013/Client/data/hdm_europe_shapes/eu-elevation.tif... failed: com.sun.media.imageioimpl.plugins.tiff.TIFFImageMetadata.getTIFFField(I)Lcom/sun/media/imageioimpl/plugins/tiff/TIFFField;

The error message is the same for java 1.7.0_51, 1.7.0_60b12, 1.8.0_00 and 1.8.0_20b5.
Open JDK 1.7.0_51 instead states the files where empty instead.

[GLASSFISH-20887] Empty Cookie Header causes an exception and a 200 ok response Created: 07/Nov/13  Updated: 03/Feb/15  Resolved: 11/Nov/13

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: suparngp Assignee: oleksiys
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Mac OS 10.9 Mavericks, Spring MVC

Tags: cookie, empty, exception, header, parsing, rest, spring


I am facing a strange issue with the Glass Fish Community Edition. I am working on a RESTful backend using Spring MVC. The front end clients are either browsers or API clients like Resty or super agent (node.js).

All the requests from the browsers are served fine. However, in case of a SuperAgent client, glass fish throws this exception:

at org.glassfish.grizzly.http.util.CookieParserUtils.parseClientCookies(CookieParserUtils.java:353)
at org.glassfish.grizzly.http.util.CookieParserUtils.parseClientCookies(CookieParserUtils.java:336)
at org.glassfish.grizzly.http.Cookies.processClientCookies(Cookies.java:220)
at org.glassfish.grizzly.http.Cookies.get(Cookies.java:131)
at org.glassfish.grizzly.http.server.Request.parseCookies(Request.java:1911)
at org.glassfish.grizzly.http.server.Request.getCookies(Request.java:1505)
at org.apache.catalina.connector.Request.parseSessionCookiesId(Request.java:4077)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:649)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:297)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:744)

After digging into this, I found out that this error is caused when a Cookie Header is being send from the client with an empty String, Like Cookie: ''. The worst part is After this exception is thrown, the request is not further processed (as expected) and a response is sent back from Glassfish with a status code of 200 OK. This is weird because any one can send a header with empty values and server shouldn't crash due to this. Secondly, if an exception is thrown, at least the status code should be like 400 Bad Request.

I was able to fix this problem temporarily by sending a dummy cookie header like Cookie: 'cook=ie'. Everything works fine in version 3 of Glass Fish.

Comment by oleksiys [ 11/Nov/13 ]

it's been fixed in trunk.

You can use this jar

to patch Glassfish 4.0

Comment by suparngp [ 12/Nov/13 ]

Thanks. I just used the above jar and patched it. The problem is resolved.

Comment by armnotstrong [ 09/Aug/14 ]

hi @oleksiys,@suparngp
I currently run in to this problem too.
I download the nucleus-grizzly-all.jar(md5sum b7fc92c73d5360f7a83d318170c4eea0) given by oleksiys, replace with it in glassfish-4.0/glassfish/modules/nucleus-grizzly-all.jar, but the problem still there.

what went wrong?

Comment by oleksiys [ 25/Sep/14 ]

try to clean up the osgi cache

Comment by cmundt [ 30/Jan/15 ]

I am not able to download the jar listed above. Is there away to resolve this in GF 4.0?

Comment by oleksiys [ 31/Jan/15 ]

The link still works for me.
Try this patch (2 files):

Comment by cmundt [ 02/Feb/15 ]

I downloaded both of these and swapped out versions in my GF 4.0 build 89.
I also cleaned up the osgi-cache under both my Domain and Instance but I am still get the same Cookie Parse error.

Comment by oleksiys [ 03/Feb/15 ]

you're right, the patch doesn't have the fix.
working on it.

correspondent Grizzly issue https://java.net/jira/browse/GRIZZLY-1530

Comment by cmundt [ 03/Feb/15 ]

@oleksisy Thanks for the update.

Comment by oleksiys [ 03/Feb/15 ]

pls. try to download same 2 files again.

Comment by cmundt [ 03/Feb/15 ]

Downloaded and tested. Appears to be working. I am awaiting developer confirmation that they are good to go.

Thanks for the quick help.

[GLASSFISH-18528] RuntimeException thown in a JASPIC swallowed and empty page returned Created: 18/Mar/12  Updated: 19/Sep/14  Resolved: 16/May/14

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: bjb Assignee: Nithya Ramakrishnan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Windows 2008, 64bits

Tags: 4_0_1-approved, debug, empty, jaspic, maze, page, security


Any RuntimeException thrown in the JASPIC implementation will result in a empty page in GF (a valid HTML page but with no content and with host encoding as meta) and no log at all (GF security logger set to finest).

IMHO, there should be an isolation so that a RuntimeEx thrown in JASPIC should be intercepted by GF's JASPIC container and :

  • if mandatory : result in a 403
  • if not mandatory : catch & log it appropriately in the security logger and go on with the next implementation configured (as per the spec)

I do not have seen anything about RuntimeEx behavior in the JSR, but this is something that should realy be handled.

FYI, the only solution is to dig with the debugger and it result into a massive loss of time, plus an cloudy situation toward the security : a page was return without clue where it came from.


Comment by Nithya Ramakrishnan [ 16/May/14 ]

A 500 Server error page would now be displayed when a Runtime exception is thrown from the SAM.

Quoting from the JASPIC spec : (Sec 3.8)

"If the request is dispatched to the resource and the resource invocation throws an exception to the
runtime, the runtime must set, within the response, an HTTP status code which satisfies any applicable
requirements defined within the servlet specification. In this case, the runtime should complete the
processing of the request without calling secureResponse"

Sending webintegration/src/main/java/com/sun/web/security/RealmAdapter.java
Transmitting file data .
Committed revision 63277.

[EL_SPEC-14] null string value is converted to "" Created: 04/Jul/13  Updated: 07/Oct/13  Resolved: 07/Oct/13

Status: Resolved
Project: el-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Works as designed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

glassfish 4.0, el 3.0

Tags: empty, jsf2_2, string


null string from JSF is converted to empty string.
I traced to code com.sun.el.lang.ELSupport 350. Should this decision be left to EL client?

Comment by Kim Haase [ 07/Oct/13 ]

I believe this bug corresponds to https://java.net/jira/browse/JAVAEETUTORIAL-249. The zip file attached to that issue reproduces the problem on EE 7. I will attach another zip file to that issue to show that the problem is new in EL 3.0, because when the test example is run in an EE 6 environment, it runs correctly.

Comment by kchung [ 07/Oct/13 ]

EL 3.0 spec (1.23.2 Coerce A to String) clearly says

If A is null: return ""

So this is behaving according to the spec.

Generated at Mon Apr 24 09:23:44 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.