You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Sachin Patel (JIRA)" <de...@geronimo.apache.org> on 2005/09/22 16:15:37 UTC
[jira] Created: (GERONIMO-1020) Fix java serialization compatibility issues across product
Fix java serialization compatibility issues across product
----------------------------------------------------------
Key: GERONIMO-1020
URL: http://issues.apache.org/jira/browse/GERONIMO-1020
Project: Geronimo
Type: Bug
Reporter: Sachin Patel
Priority: Critical
>From dev list post...
So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1020) Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
Posted by "David Blevins (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=all ]
David Blevins reassigned GERONIMO-1020:
---------------------------------------
Assign To: Sachin Patel (was: David Blevins)
Patch looks good. Go for it.
> Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
> ---------------------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Components: kernel
> Versions: 1.0-M5
> Reporter: Sachin Patel
> Assignee: Sachin Patel
> Priority: Critical
> Fix For: 1.0-M5
> Attachments: patch.txt
>
> From dev list post...
> So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
> A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
> Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
> So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
> I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1020) Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
Posted by "Sachin Patel (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=all ]
Sachin Patel updated GERONIMO-1020:
-----------------------------------
Summary: Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType (was: Fix java serialization compatibility issues across product)
Agree. Changing title.
> Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
> ---------------------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Reporter: Sachin Patel
> Priority: Critical
>
> From dev list post...
> So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
> A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
> Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
> So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
> I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1020) Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
Posted by "David Blevins (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=all ]
David Blevins reassigned GERONIMO-1020:
---------------------------------------
Assign To: David Blevins
> Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
> ---------------------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Components: kernel
> Versions: 1.0-M5
> Reporter: Sachin Patel
> Assignee: David Blevins
> Priority: Critical
> Fix For: 1.0-M5
> Attachments: patch.txt
>
> From dev list post...
> So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
> A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
> Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
> So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
> I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1020) Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
Posted by "Sachin Patel (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=all ]
Sachin Patel updated GERONIMO-1020:
-----------------------------------
Attachment: patch.txt
> Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
> ---------------------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Reporter: Sachin Patel
> Priority: Critical
> Attachments: patch.txt
>
> From dev list post...
> So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
> A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
> Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
> So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
> I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1020) Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
Posted by "Sachin Patel (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=all ]
Sachin Patel closed GERONIMO-1020:
----------------------------------
Resolution: Fixed
Fix went into both head and m5 branch.
> Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
> ---------------------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Components: kernel
> Versions: 1.0-M5
> Reporter: Sachin Patel
> Assignee: Sachin Patel
> Priority: Critical
> Fix For: 1.0-M5
> Attachments: patch.txt
>
> From dev list post...
> So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
> A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
> Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
> So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
> I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1020) Fix java serialization compatibility issues across product
Posted by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=comments#action_12330236 ]
Aaron Mulder commented on GERONIMO-1020:
----------------------------------------
I don't think this is a useful report. It needs a list of specific classes, or you need to submit bugs for speecific classes as you come across them, or something. As is, it can never be closed, because we'll never add a serial version ID to every class in the product and we'll never know if the ones we've missed will cause problems. So I think we need to handle specific classes as we become aware of them.
Are you OK changing this report to be "Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType"?
> Fix java serialization compatibility issues across product
> ----------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Reporter: Sachin Patel
> Priority: Critical
>
> From dev list post...
> So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
> A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
> Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
> So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
> I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: How to deploy a webapp on Tomcat Geronimo
Posted by Chris Cardona <ja...@yahoo.com>.
Thanks for you help David! I'll give it a try.
--- David Jencks <da...@yahoo.com> wrote:
> The easiest way is:
>
> cd modules/assembly
> maven -o tomcat
>
> then deploy your web app as usual.
>
> This basically changes the contents of config.list
> and config.xml so
> deployments get routed to tomcat rather than jetty.
> You can make the
> same changes yourself :-)
>
> Hope this helps
> david jencks
>
> On Sep 22, 2005, at 1:09 PM, Chris Cardona wrote:
>
> > Not sure if somebody already asked about this but
> how
> > do we deploy a webapp on Tomcat Geronimo? Right
> now
> > everything is deployed by default on Jetty. I've
> > checked the devlist and I haven't seen any info so
> > far.
> >
> > Thanks for any help.
> >
> > Chris
> >
> >
> >
> > __________________________________
> > Yahoo! Mail - PC Magazine Editors' Choice 2005
> > http://mail.yahoo.com
> >
>
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Re: How to deploy a webapp on Tomcat Geronimo
Posted by David Jencks <da...@yahoo.com>.
The easiest way is:
cd modules/assembly
maven -o tomcat
then deploy your web app as usual.
This basically changes the contents of config.list and config.xml so
deployments get routed to tomcat rather than jetty. You can make the
same changes yourself :-)
Hope this helps
david jencks
On Sep 22, 2005, at 1:09 PM, Chris Cardona wrote:
> Not sure if somebody already asked about this but how
> do we deploy a webapp on Tomcat Geronimo? Right now
> everything is deployed by default on Jetty. I've
> checked the devlist and I haven't seen any info so
> far.
>
> Thanks for any help.
>
> Chris
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>
How to deploy a webapp on Tomcat Geronimo
Posted by Chris Cardona <ja...@yahoo.com>.
Not sure if somebody already asked about this but how
do we deploy a webapp on Tomcat Geronimo? Right now
everything is deployed by default on Jetty. I've
checked the devlist and I haven't seen any info so
far.
Thanks for any help.
Chris
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
[jira] Updated: (GERONIMO-1020) Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
Posted by "Sachin Patel (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=all ]
Sachin Patel updated GERONIMO-1020:
-----------------------------------
Fix Version: 1.0-M5
Version: 1.0-M5
(was: 1.0)
Can we get this into M5?
> Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
> ---------------------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Components: kernel
> Versions: 1.0-M5
> Reporter: Sachin Patel
> Priority: Critical
> Fix For: 1.0-M5
> Attachments: patch.txt
>
> From dev list post...
> So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
> A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
> Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
> So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
> I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1020) Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
Posted by "Sachin Patel (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=all ]
Sachin Patel updated GERONIMO-1020:
-----------------------------------
Component: kernel
Version: 1.0
> Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
> ---------------------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Components: kernel
> Versions: 1.0
> Reporter: Sachin Patel
> Priority: Critical
> Attachments: patch.txt
>
> From dev list post...
> So if you are not aware, I'm pulling in and packaging several jars from the lib and lib/endorsed directory into one of the eclipse plug-in, so the classes can be used and referenced by the rest of the eclipse plugins. This is because eclipse can not reference classes or jars at runtime that are not packaged within a plug-in and marked as visible in either the plugin.xml or manifest.
> A big problem resides as now the same jars I'm packaging must be the same exact jars that reside in the target server I'm deploying. This causes a dependency on a particular server image. If a user modifies classes I reference and rebuilds their server, the plug-in is broken as during deployment I'll receive error messages like the following...
> Caused by: java.io.InvalidClassException: org.apache.geronimo.kernel.config.ConfigurationModuleType; local class incompatible: stream classdesc serialVersionUID = 6296527685792707191, local class serialVersionUID = -4121586344416418391
> So looking at that particular class, it looks like the serialVersionUID is generated by Java compiler. This is bad as now jars/classes risk compatibility between every build. We need a solution for this. The only other option I'm aware of is for these serializable classes to hard code and explicity assign a value. Of course we must then assue that we manually maintain backward compatibility to support the N-2 model for these classes. This problem will eventually have to be solved anyway when there is multiple server support and across different versions.
> I think this is a must fix for 1.0 as without doing so we risk product migration, mixed version interoperability, tooling, possibly user applications, etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira