Issue Details (XML | Word | Printable)

Key: GLASSFISH-16954
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Byron Nevins
Reporter: mkarg
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
glassfish

asadmin complains about "Unknown plain text format" when deployment fails

Created: 04/Jul/11 11:58 AM   Updated: 24/Oct/11 08:16 PM   Resolved: 13/Jul/11 08:13 AM
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. File basicwebapp.war (9 kB) 11/Jul/11 09:50 PM - Byron Nevins

Environment:

Win7 Pro SP1 64 Bit de_DE


Tags: 3_1_1-exclude 3_1_1-scrubbed 3_1_x-exclude
Participants: Byron Nevins, Hong Zhang, mkarg, Tim Quinn and Tom Mueller


 Description  « Hide

I am trying to deploy an application using "asadmin deploy --retrieve . SuperSimple.ear". Due to a bug in that EAR, deployment fails. This is a typical situation when still in development, so asadmin should be clever enough to handle this with a message like "Deployment failed due to...".

But what it actually says is "Unknown plain text format.". Least programmers will understand that this actually means: "Everything is OK, you just have a typo in your EAR"...!

c:\Users\Karg\workspace\CreateComplaintsRS\dist>C:\glassfish3\bin\asadmin deploy --retrieve . SuperSimple.ear
remote failure: Unknown plain text format. A properly formatted response from a PlainTextActionReporter
always starts with one of these 2 strings: PlainTextActionReporterSUCCESS or PlainTextActionReporterFAILURE. The response we re
ceived from the server was not understood: Signature-Version: 1.0
message: Error occurred during deployment: Exception while preparing t
he app : Exception [EclipseLink-28018] (Eclipse Persistence Services

  • 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityMa
    nagerSetupException
    Exception Description: Predeployment of
    PersistenceUnit [QUIPSY] failed.
    Internal Exception: Excepti
    on [EclipseLink-7163] (Eclipse Persistence Services - 2.2.0.v20110202
    %%%EO13): org.eclipse.persistence.exceptions.ValidationException
    L%%%Exception Description: Entity class [class de.quipsy.persistency.
    suppliedPart.SuppliedPartPk] has both an @EmbdeddedId (on attribute [
    pk]) and an @Id (on attribute [customerId]. Both ID types cannot be s
    pecified on the same entity.. Please see server.log for more details.

Exception while invoking class org.glassfish.persistence.jpa
.JPADeployer prepare method : javax.persistence.PersistenceException:
Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.2.0.
v20110202-r8913): org.eclipse.persistence.exceptions.EntityManagerSet
upException
Exception Description: Predeployment of Persiste
nceUnit [QUIPSY] failed.
Internal Exception: Exception [Ecli
pseLink-7163] (Eclipse Persistence Services - 2.2.0.v20110202-r8913):
org.eclipse.persistence.exceptions.ValidationException
Exce
ption Description: Entity class [class de.quipsy.persistency.supplied
Part.SuppliedPartPk] has both an @EmbdeddedId (on attribute [pk]) and
an @Id (on attribute [customerId]. Both ID types cannot be specified
on the same entity.
Exception [EclipseLink-28018] (Eclipse P
ersistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence
.exceptions.EntityManagerSetupException
Exception Description: Prede
ployment of PersistenceUnit [QUIPSY] failed.
Internal Exception: Exc
eption [EclipseLink-7163] (Eclipse Persistence Services - 2.2.0.v2011
0202-r8913): org.eclipse.persistence.exceptions.ValidationException

Exception Description: Entity class [class de.quipsy.persistency.supp
liedPart.SuppliedPartPk] has both an @EmbdeddedId (on attribute [pk])
and an @Id (on attribute [customerId]. Both ID types cannot be speci
fied on the same entity.
name_value: SuperSimple
name_name: name
keys: name
use-main-children-attribute: false
exit-code: FAILURE

Command deploy failed.

c:\Users\Karg\workspace\CreateComplaintsRS\dist>



mkarg added a comment - 04/Jul/11 11:59 AM - edited

In addition to that nasty and wrong message, it is not very smart that my CLI can handle e. g. 160 columns per row, but GlassFish decides to just send much less (80 or so): Yes, the above formatting was done by GlassFish, not by me...!

That's not You and it's not GlassFish. It's the JDK 1.1 Manifest class doing the formatting.


Tom Mueller added a comment - 05/Jul/11 01:47 PM

I'm not sure if this is a bug in the deploy command or in the response framework, so I'm assigning this to Tim first to see if it is a bug in deploy. If it is a bug in the response framework, please assign to Byron.


Tim Quinn added a comment - 05/Jul/11 04:15 PM

Markus,

Which build of GlassFish are you using?

Can you please attach your app to this issue? It would help us in recreating exactly the conditions which cause the problem you noted. If you would rather not post it publicly you can e-mail it to me directly if you prefer.


Tim Quinn added a comment - 05/Jul/11 10:22 PM

Using a current build of 3.1.1, I deployed an app that creates tables in the database during deployment. Then I undeployed without removing the tables. The next deployment of the app was reported as "completed with warnings" after listing the database messages because the tables were already there.

I am not using Markus's application, so there clearly could be important differences. But at least in 3.1.1 this case looks to be working.

Markus, this emphasizes how valuable it will be for me to use your app itself. Thanks.


mkarg added a comment - 06/Jul/11 07:22 AM

Tim, wanted to send you my EAR, but your server first refused the mail due to it's size, then refused to accept any mails:

tjquinn@oracle.com on 06.07.2011 09:20
The message cannot be delivered due to a configuration error on the server. Please contact your Administrator.
<quipsy.de #5.3.0 smtp;553 5.3.0 <tjquinn@oracle.com>... 550:5.7.1 Email address is not available.>

Can you please send me an email addess to karg@quipsy.de where I can push the EAR to?


mkarg added a comment - 06/Jul/11 11:34 AM

Tim, cannot answer to the email you sent me via att.net:

Your message did not reach some or all of the intended recipients.

Subject: RE: Getting your app to test the GlassFish issue
Sent: 06.07.2011 13:26

The following recipient(s) cannot be reached:

Tim Quinn on 06.07.2011 13:26
There was a SMTP communication problem with the recipient's email server. Please contact your system administrator.
<quipsy.de #5.5.0 smtp;521-87.234.217.170 blocked by sbc:blacklist.mailrelay.att.net.>

If you like I can upload the encrypted ZIP to our public FTP server, but how to send you the secret password?


Tim Quinn added a comment - 06/Jul/11 10:16 PM

I have diagnosed this problem this far:

The server is using a PropsFileActionReporter to capture the result of this command (as it does for all asadmin commands).

The admin CLI client fails, though, when it tries to convert the response into a Manifest (which is how command results are returned to the client after admin command execution). I stepped through it enough to know that the Attributes class (in Java SE) throws an IOException with "invalid header field" – from line 389 in the Attributes class - from the invocation of the Manifest(InputStream) constructor in the AdminCommandResponse constructor.

Because the RemoteResponseManager assumes that any IOException in reading the input stream as a manifest is due to it not being a manifest - as opposed to it being a manifest that's not properly formatted - it goes on and tries to interpret it as a plain text response message - which it is not - and that code then complains because the response lacks one of the expected prefixes for plain text responses.

I suspect that by composing the message for the action report by adding on the exception message is what's causing the problem. Looking at the message Markus posted in his original description, there is a blank line followed by

Exception while invoking class org.glassfish.persistence.jpa
.JPADeployer prepare method : (more text)

which I suspect the Manifest constructor is trying to interpret as a manifest attribute. Because the text to the left of the : is not a legal attribute name, the Attributes class throws the IOException.

I am looking at an inexpensive way to process such error messages in DeployCommand to prevent the manifest reader from incorrectly interpreting the error display as an attribute.


Tim Quinn added a comment - 06/Jul/11 10:52 PM

As Tom suggested earlier, I am reassigning this to Byron.

The PropsFileActionReporter's setMessage method needs to format the message in a way that the message cannot be confused as a manifest attribute setting. It already does some similar work to handle line separators in the message.

This is not something the caller should do, because other formats of reporter do not have this restriction and other places other than the caller in this case (DeployCommand) might set the message to similar unfriendly values.


mkarg added a comment - 07/Jul/11 06:39 AM

Side note: The above explanation is a good example while people nowadays tend to prefer REST. A RESTful asadmin would just do a HTTP PUT with the complete EAR, the server would try to deploy it, and send one single XML file back with a list of all deployment issues, which asadmin can parse by simple JAXP.unmarshal(file). No need to fiddle around with custom classes and complex things like Manifests and PropsFileActionReporters etc. Maybe the asadmin team likes to think about that for GF 4...


mkarg added a comment - 11/Jul/11 09:38 AM

Any news?


Byron Nevins added a comment - 11/Jul/11 05:17 PM

I have no way to reproduce this. There is no ear attachment.


Byron Nevins added a comment - 11/Jul/11 05:41 PM

Please attach the output when AS_DEBUG is set to true.


Byron Nevins added a comment - 11/Jul/11 05:42 PM

Reopen after providing a way to reproduce please...


Tim Quinn added a comment - 11/Jul/11 06:58 PM

Marcus provided a sample app which I will (separately) send to Byron.


Byron Nevins added a comment - 11/Jul/11 07:05 PM

Is there something wrong with attaching it to JIRA?


Byron Nevins added a comment - 11/Jul/11 07:30 PM

I will reopen this if and when I can reproduce it.


Tim Quinn added a comment - 11/Jul/11 07:35 PM - edited

As I wrote to Byron separately, the app cannot be shared publicly so it cannot be attached to the issue.

Turns out my earlier e-mail to Byron did not go through. I am providing him the sample app separately.


Byron Nevins added a comment - 11/Jul/11 09:50 PM

Mitesh says this should demonstrate the bug


Byron Nevins added a comment - 11/Jul/11 09:55 PM

Nope. That war file does NOT show the bug:

=== This Issue remain non-reproducible ===

fetchCommandModel: got command opts: com.sun.enterprise.admin.util.CommandModelData@1037c71
doHttpCommand succeeds
Process program options
Parsing program options
Parse command options
params: {}
operands: [basicwebapp.war]
Prevalidate command options
Inject command options
Validate command options
asadmin --host localhost --port 4848 --user admin --interactive=true --echo=false --terse=true deploy --force=false --precompilejsp=false --verify=fal
se --generatermistubs=false --availabilityenabled=false --asyncreplication=true --keepreposdir=false --keepfailedstubs=false --isredeploy=false --logr
eportederrors=true basicwebapp.war
Execute command
removing --upload option
doUpload set to false
FILE PARAM: DEFAULT = D:\j2eeapps\basicwebapp.war
URI: /__asadmin/deploy?DEFAULT=D%3A%5Cj2eeapps%5Cbasicwebapp.war
URL: com.sun.enterprise.admin.util.HttpConnectorAddress@1ef8cf3
URL: http://localhost:4848/__asadmin/deploy?DEFAULT=D%3A%5Cj2eeapps%5Cbasicwebapp.war
Password options: null
Using auth info: User: admin, Password: <null>
------- RAW RESPONSE ---------
Signature-Version: 1.0
message: Error occurred during deployment: Exception while preparing t
he app : Exception [EclipseLink-28018] (Eclipse Persistence Services

  • 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityMa
    %%%EOL%%%Exception Description: Predeployment of
    %%%EOL%%%Internal Exception: Excep.
    tion [EclipseLink-7333] (Eclipse Persistence Services - 2.2.0.v201102
    %%%-r8913): org.eclipse.persistence.exceptions.ValidationException
    EOL%%%Exception Description: The reference column name [foo] mapped o
    n the element [field userCredentials] does not correspond to a valid
    field on the mapping reference.. Please see server.log for more detai
    ls.
    name_value: basicwebapp
    name_name: name
    keys: name
    use-main-children-attribute: false
    exit-code: FAILURE

------- RAW RESPONSE ---------
PROCESSING MANIFEST...
remote failure: Error occurred during deployment: Exception while preparing the app : Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.
2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Predeployment of PersistenceUnit [pujavaee] failed.
Internal Exception: Exception [EclipseLink-7333] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.Validation
Exception
Exception Description: The reference column name [foo] mapped on the element [field userCredentials] does not correspond to a valid field on the mappi
ng reference.. Please see server.log for more details.
Command deploy failed.

d:\j2eeapps>


Byron Nevins added a comment - 13/Jul/11 12:26 AM

Comment from my code checkin

16954
GIGO. The server, actually Deployment, is sending back a corrupt (garbage!!) Manifest object. The JDK Manifest class implementation itself fails to parse it.
There is absolutely nothing that CLI can do to "fix" this.
BUT – the error message was not correct – it incorrectly assumed that it was a badly formatted plaintext return object.
I fixed the error message. The real fix must be done server-side in deployment code.


Hong Zhang added a comment - 13/Jul/11 01:44 AM

assign to tim to follow up as tim had previously worked on it already


Tim Quinn added a comment - 13/Jul/11 02:19 AM

I do not see how it is deployment that is the problem here. Deployment invokes the published methods on ActionReport to set the report's message. (DeployCommand, line 440)

It should be up to the various report implementations - such as PropsFileActionReporter - to do the right thing with the values presented to it. Because it's PropsFileActionReporter that knows it expresses the report as a manifest, it should be that class that does whatever is needed to correctly handle any value passed to it so it does not create an invalid manifest.

I'm passing the baton back to the admin component, because it cannot be deployment's responsibility to know that the particular implementation of ActionReport at hand is not handling the message correctly.


Byron Nevins added a comment - 13/Jul/11 08:13 AM

Original problem is resolved