IPlanet 4.1 & class reloading

Hi all,
i'm using iPlanet web server 4.1(FastTrack Ent. Edition) and just can't figure out how to automatically reload the user classes instantiated from my servlet. The latter is in /usr/netscape/server4/docs/servlet but the user classes are in a different location, /usr/test. I'd like to be able to make changes to these user classes w/o having to restart the webserver every time in order to reload these.
please help...

Hi,
1) stop the server
2) In the contexts.properties file, edit the following property: context.global.isModifiedCheckAggressive=true
3) start the server
(got this from http://knowledgebase.iplanet.com/ikb/kb/articles/4339.html )
Hope this helps,
Kurt.

Similar Messages

Re: [iPlanet-JATO] jato classes serializable

Unless Todd, Mike, or Matt have slick answer to make it work, my only
solution would be to switch from using the objects themselves and
reference by name instead. I don't know exactly what your Utility class
is doing or how the fields use the Utility class, so I can not be
specific in what you should do.
I fear that I may be taking on too much work by asking, but maybe you
could send me the Utility class (send to me directly as Yahoo Groups
doesnot allow attachments: craig.conover@s...).
I'll take a quick glance at it. Maybe I can make some suggestions to
minimize your migration efforts.
craig
Seetharam, Prashanth wrote:
In ND, we had a utility class written whose member variables were visual
objects. This utility object is used to display or not display its elements
depending on user action. The utility object was being put into session.
It could have been implemented in a different way, by storing visual object
names instead of objects themselves. But when we migrated, we tried to keep
re-coding to the minimum and ended up replacing ND visual objects
withcorresponding jato visual objects and ran into this problem.
Since all the jato visual objects extend from DisplayFieldBase which inturn
extends from ViewBase, i started looking at ViewBase and did not understand
why the variable was made transient. Hence the question.
Thanks,
Prashanth Seetharam
-----Original Message-----
From:     Craig V. Conover [SMTP:<a href="/group/SunONE-JATO/post?protectID=219212113009229091025149066024064239039098031198039130252055210">craig.conover@s...</a>]
Sent:     Tuesday, December 11, 2001 2:43 PM
Subject:     Re: [iPlanet-JATO] jato classes serializable
What is your requirement that these be serializable?
The views do not store any values, that is what the model is for, and
they are created lazily as needed.
Is there something you were doing in ND that required it. It is very
likely that you do not need to do it anymore with JATO.
If you are using JATO1.0, you are highly encouraged to start using JATO
1.2. If you are using the iMT, it has an upgrade tool for 1.x to 1.2.
http://developer.iplanet.com/tech/appserver/framework/index.jsp
I'll leave the transient parentViewBean to Todd or Mike to justify. But,
again, what is the need for it to be serialized?
c
Seetharam, Prashanth wrote:
I am using jato1.0 and found that jato classes (especially the visual
objects like StaticTextField) are not serializable.
Is this change made in jato1.1? It will be good to have this feature as
ND
visual objects were serializable.
Also in com.iplanet.jato.view.ViewBase.java, why has this variable been
made
transient?
     private transient ViewBean parentViewBean;
Thanks,
Prashanth Seetharam
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Unless Todd, Mike, or Matt have slick answer to make it work, my only
solution would be to switch from using the objects themselves and
reference by name instead. I don't know exactly what your Utility class
is doing or how the fields use the Utility class, so I can not be
specific in what you should do.
I fear that I may be taking on too much work by asking, but maybe you
could send me the Utility class (send to me directly as Yahoo Groups
doesnot allow attachments: craig.conover@s...).
I'll take a quick glance at it. Maybe I can make some suggestions to
minimize your migration efforts.
craig
Seetharam, Prashanth wrote:
In ND, we had a utility class written whose member variables were visual
objects. This utility object is used to display or not display its elements
depending on user action. The utility object was being put into session.
It could have been implemented in a different way, by storing visual object
names instead of objects themselves. But when we migrated, we tried to keep
re-coding to the minimum and ended up replacing ND visual objects
withcorresponding jato visual objects and ran into this problem.
Since all the jato visual objects extend from DisplayFieldBase which inturn
extends from ViewBase, i started looking at ViewBase and did not understand
why the variable was made transient. Hence the question.
Thanks,
Prashanth Seetharam
-----Original Message-----
From:     Craig V. Conover [SMTP:<a href="/group/SunONE-JATO/post?protectID=219212113009229091025149066024064239039098031198039130252055210">craig.conover@s...</a>]
Sent:     Tuesday, December 11, 2001 2:43 PM
Subject:     Re: [iPlanet-JATO] jato classes serializable
What is your requirement that these be serializable?
The views do not store any values, that is what the model is for, and
they are created lazily as needed.
Is there something you were doing in ND that required it. It is very
likely that you do not need to do it anymore with JATO.
If you are using JATO1.0, you are highly encouraged to start using JATO
1.2. If you are using the iMT, it has an upgrade tool for 1.x to 1.2.
http://developer.iplanet.com/tech/appserver/framework/index.jsp
I'll leave the transient parentViewBean to Todd or Mike to justify. But,
again, what is the need for it to be serialized?
c
Seetharam, Prashanth wrote:
I am using jato1.0 and found that jato classes (especially the visual
objects like StaticTextField) are not serializable.
Is this change made in jato1.1? It will be good to have this feature as
ND
visual objects were serializable.
Also in com.iplanet.jato.view.ViewBase.java, why has this variable been
made
transient?
     private transient ViewBean parentViewBean;
Thanks,
Prashanth Seetharam
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp

Dynamic class reloading in modular web application

Hi.
My web application has these requirements:
A. Functional modularization (like plug-ins). Modules will be simple jars containing application logic classes: dto beans, business logic services, dao (jpa), framework stuff (Struts2), etc...
B. At runtime and without restarting the application "class loading" must be aware of classes inside new, changed and removed modules.
C. Some of these jars will be outside the web application folder (WEB-INF/lib), possibly outside the container itself too.
My question:
1. Can I achieve all or some of my requirements with a Java web application?
2. How should I manage the modules?
3. Do I need some special web container feature (maybe osgi)?
4. Can I use a custom class loader in my application?
The architecture objectives are:
I. Provide scalability.
II. Efficient development process (independent deployment and no application restart required).
III. Better production support (no application restart required for changes).
More on the architecture:
a). Functional scalability, meaning this that my application may functionally grow up to an indeterminate number of small functional modules.
b). Modules will be developed, deployed and maintained independently so the application discovers and loads classes on demand.
c). Avoid a big .war file containing all the small modules because a small change in one module would involves deploying all the other modules (possibly hundreds o even thousands of them) and restarting the application.
d). Above point involves dynamic class reloading.
I guess this is addressed by OSGI (looks like heavy to deal with), Jigsaw (still under development) and maybe others. I think the key point is the class loader. I will develop a custom class loader but maybe you have some advice for me before starting to develop.
Thanks and regards.

Classes maintained by the container should not be loaded by an application. You want the container to read those classes and react accordingly. Most of those classes are read when the container starts up a container restart will be required. Trying to leverage another container within a container does not sound like it will be worth (if you can get it to work).
Perhaps you should state the problem that you are trying to solve with these modules so that others may suggest more feasible solutions to achieve your target goals.

Dynamic Class Reloading

As I know that setting has to be made to the application server to enable the class reloading features, so that the changes to the components (such as enterprise beans, servlets, and JSP files) to a running server can be deployed without having to stop the application server process and start it again.
I'm just wondering, for those Web Hosting Company that offer JSP-compatible Web Servers services, are they forced to have the Class Reloading Feature enabled for their Web Server?? else how they can provided 7 x 24 service, as no downtime are allowed, please advise?

"... else how they can provided 7 x 24 service, as no downtime are allowed, please advise?"
Most large organisations wishing to redeploy an application but maintain service would not use class reloading (which would be a path to chaos!) but would use their load balancers or clustering software to disable connections to some (half?) of their servers. They'd then load the updated software onto the out-of-service servers, swich the live traffic onto them and then update the remaining servers before bringing them back into service.
This kind of redeployment can also be achieved by running more than one instance of the app server on each box, with only one instance 'live' at any one time. Updates are made to the off-line instances and then connections redirected to them. This has the advantage that the old code is still in place so fall-back is easy if there's a problem with the redeployed code.

Guru question, class reloading, resolved symbols

How can I determine all of the class symbols that get
resolved in a java class file? I want this from java, the
utility javap doesn't really fit the bill since it doesn't
give me the information I want.
BACKGROUND
I'm creating a class reloader which loads many packages. In order to get the reloading effect, a new
class loader must be instantiated...which is fine. The usual approach is to reload every class on the class path, but this is too time consuming. I would like to
be more elegant and only reload the minimum set of class files and delegate appropriately.
In order to do this I need need to know all of the symbols used by a particular class. For example,
if a class ABC has a method that uses class XYZ, and
XYZ gets modified to be XYZ'. I need to reload ABC if
I reload XYZ', otherwise ABC will use XYZ. This is
behavior spec'ed in JVM class loader spec (5.3).
The JVM spec also outlines the format of the
class file, but I really don't want to parse this myself.
Are there any utilities to facilitate inspecting class
files and getting this kind of information.

The usual approach is to reload every class on the class path...Huh? I was rather certain that classes were loaded as needed, not as found.
I need to reload ABC if I reload XYZ', otherwise ABC will use XYZ.
This is behavior spec'ed in JVM class loader spec (5.3).I don't understand this either. You can't 'reload' XYZ. You can load a different class. Or you can use a different class loader and load the a class with the same name (although the jvm will treat it as a different class.) Or you can wait for the jvm to collect the class loader (which means no instances of XYZ at a minimum) and then load what ever you want. Reloading to me suggests that you are some how replacing the existing class and that can't happen.
If the only reference in ABC is a method (local and not static) then I don't believe the class will be loaded until the method is called.
Whatever class loader loaded ABC and XYZ will not be gc'd until there are no instances of the classes it loaded. So if both use the same class loader then by definition when you load ABC, when you get a chance to load XYZ you can do whatever you want.
So, given the above, I am not sure I understand the question.

Clarification needed on servlet class reloading

          I have a question about servlet reloading in WLS6.0
          Let's assume i have version 1.0 of a SomeServlet.class loaded in WLS.
          Client are accessing it currently.
          Now let's say i create version 1.1 of SomeServlet.class and i want to deploy it in WLS.
          I have the "servlet reloading" turned ON.
          So that means that version 1.1 will be immediately loaded by WLS right?
          Question: Will WLS first unload version1.0? If so, what happens to the clients who are using version 1.0?
          Will they get a ClassCastException? Or will they be abruptly switched from 1.0 to 1.1? Will they see any any error at all?
          Thanks.
          PS: If i had deployed the servlet in a WAR file, will the same rules apply? In other words, if i replace the WAR file will a newer version, what will happen to the classes from the previous WAR file that are being used by clients.
          Is there a document explaining "how WLS reloads/hot-deploys servlets/ejb"? I understand that WLS6.0 uses a new "classloader architecture" that is different from WLS5.1.0. Some document to explain the differences would be helpful. Thanks.


The new version will be loaded immediately into a new classloader.
          The old version will remain (in its old classloader) until there are no
          longer any references to it (which will happen when clients that were
          using the old version have completed their operations).
          mark
          Jeff Mathers wrote:
          > Did you ever get clarification on this point?
          >
          > I am trying to figure out how to force WLS 6 to reload servlets following a
          > re-compile. Your message hinted at a way to do this. Can you fill me in?
          >
          > Jeff Mathers
          > IT R&D
          > RWJPRI - Johnson & Johnson
          >
          > "R" <[email protected]> wrote in message
          > news:[email protected]...
          > >
          > > I have a question about servlet reloading in WLS6.0
          > >
          > > Let's assume i have version 1.0 of a SomeServlet.class loaded in WLS.
          > > Client are accessing it currently.
          > > Now let's say i create version 1.1 of SomeServlet.class and i want to
          > deploy it in WLS.
          > > I have the "servlet reloading" turned ON.
          > > So that means that version 1.1 will be immediately loaded by WLS right?
          > >
          > > Question: Will WLS first unload version1.0? If so, what happens to the
          > clients who are using version 1.0?
          > > Will they get a ClassCastException? Or will they be abruptly switched from
          > 1.0 to 1.1? Will they see any any error at all?
          > >
          > > Thanks.
          > >
          > > PS: If i had deployed the servlet in a WAR file, will the same rules
          > apply? In other words, if i replace the WAR file will a newer version, what
          > will happen to the classes from the previous WAR file that are being used by
          > clients.
          > >
          > > Is there a document explaining "how WLS reloads/hot-deploys servlets/ejb"?
          > I understand that WLS6.0 uses a new "classloader architecture" that is
          > different from WLS5.1.0. Some document to explain the differences would be
          > helpful. Thanks.

Thoughts: Versioning, Class Reloading, ClassLoaders

Recently on Ted Neward's weblog there was a discussion about the limitations of the ClassLoader architecture: http://neward.net/ted/weblog/index.jsp?date=20030215 Ted offers some suggestion for improving the architecture, and it got me to thinking about a few related changes that I think might make the classloading more powerful and allow for quicker, cleaner updates of Java while giving you more control over how the updates affect your existing code. Now bear with me on this, it's not too well thought out, but I figured I'd start it and see what you guys all think.
(There are Three Changes)
The first change would be to build version-checking/loading directly into the classloader architecture. With version-checked loading, Sun (and developers) can deploy incremental updates without the need for delivery of an entirely new jdk/jre (e.g. rt.jar).
The second change is what could come out of using a version-checked loading method: You could set your code to use specific versions.
Example:
In the new Isolate API, it will be necessary to update java.lang.System to work differently than the current version. Let's say I want to run old apps as I always did, and some new apps using the new version of System. Simply start the JVM with -Djava.runtime.version=1.3 (or whatever) for runtime packages and -Djava.version.package=com.mycompany.data[1.3+] for third party packages. With this information the classloader automatically loads the proper version.
The third change (again drawing from the previous two):
Allow the System ClassLoader to redefine classes (not just arbitrarily, bear with me here). To fully realize the power of byte-code engineering, and dynamic runtime classes/decisions, I believe classes need to be able to be redefined. HOWEVER, I think this would HAVE to be coordinated with the versioning system. Let me explain:
When a class is defined it would automatically be given a version (whether or not you specify one) within the VM - maybe considered a "Runtime version number." When you redefine a class, you would have to specify a new version (there would be a required syntax for this that Java "forces" you to follow so we all would do it the same). CodeSources would then (in the jar?) specify whether they can use that new version, maybe like this:
compatibility:
package com.me.data.* + //ANY VERSION
package com.me.io.* 1.2+ //1.2 OR LATER As well, it would be done on a major/minor version system, so any minor versions would be assumed to be compatible with anything taking the major version of that (So if I can use 1.3, then any 1.3.1 has to be compatible with my code) Otherwise, these classes continue to use the earlier version.
One thing that might also be added (not sure if nec), is some extra methods (similar to Serialization methods?) to facilitate the reloading. So if my class uses a package that can be updated, then I have the ability to implement the method public void packageReloaded(String packageName, String version)? (Not sure this would be needed) but even if I do not implement that method, the JVM could still update the class, in a default manner. This is not well thought out and would need more time, but I think this could make Java VERY powerful in terms of ability to handle dynamic systems and architectures. (What issues are raised by something like this?)
As well, it would need security to be better thought out. I'm thinking that CodeSource-based permissioning is a poor concept when you're dealing with dynamically created classes that have no file (they're generated at runtime). So there would need to be an update of the security architecture for this - and a maybe way to ensure that only Sun/and/or the owner of this particular JVM installation updates the package java.* for example.

I don't know enough about class loading and such to really critique your suggestions, but I know the ability to upgrade only certain packages would definitely be nice. The only non-technical drawback that comes to mind is vendor support. Right now, an application server has a set of Java versions that it supports. With this change now maybe it supports Java 1.5 plus the NIO package version 1.6 plus javax.servlet 1.7, etc you get the idea. But that's just an inconvenience, not a roadblock.

WEB-INF/lib class reloading

Are the jar/zip files placed in the WEB-INF/lib directory
of the web app reloadable i.e. if the classes in the jar file
are changed would they be reloaded by the webapp
class loader just like the classes in the WEB-INF/classes
directory?

1ro que nada te aconsejo que respondas en ingles... este es un foro en esa lengua.
si tu ingles es malo te sugiero que uses http://babelfish.altavista.com
2) do you have include the Reports library in yours projects.

NON-SERVLET, NON-EJB DYNAMIC CLASS RELOAD

hi,
          In weblogic 5.1, is there a way to reload a class from the clientclasses directory without restarting the server? it's just a class in the clientclasses used by the JSPs. a kind of hotdeploy for NON-EJB, NON-SERVLET CLASS. SPECIFIC guidance will be immensely appreciated..
          Thanks in advance
          Vijay


please show us the full error message.
it sounds like a classpath problem...

'Static' class reloading

OK - there are no static classses but. . .
For a class which provides no way to create an instance of itself, does the class loader ever remove the class from memory?
For instance, assume class Foo has a hugh static initializer. No other classes ever hold a reference to Foo, but they do occasionally call static methods of Foo. Will the class loader ever drop Foo from memory, then reload it (re-executing the static initializer and assigning the static fields) when another class calls one of Foo's static methods?
If not, do class definitions pile up endlessly in memory?
Thanks,
Eric Everman

do class definitions pile up endlessly in memory?Yes, if there are endless class definitions to load.
Maybe I should ask this one back to you:
does program have endless new class definitions to load?[b]
--lichu

How to disable class reloading feature

Hi,
how can I disable the reloading of servlet classes in oc4j?
Thanks
GÃ¼nther

no answer?
Please help me!
Thanks
GÃ¼nther

Weird tomcat problem (class reloading)

i have very weird problem with tomcat 3.2.3.
for example i have html page which calls servlet.
everything is fine when i start tomcat. now when i
recompile servlet and try to call it again, this is
what i get:
Internal Servlet Error:
java.lang.IllegalStateException: Can't happen -
classname is null, who added this ?
at
org.apache.tomcat.core.ServletWrapper.loadServlet(ServletWrapper.java:261)what kind of error is this and what causes it? it
happens even if i try to refresh html page after
compiling.
is there any way to fix this because it is realy
tiring to restart tomcat each time i recompile
servlet.
thanx for help

Tomcat has to be restarted after recompiling any
servlet-class that was already invoked by tomcat.It's
the price you have to pay for a free server.
I think that this is not right. You can specify that an application context is "reloadable" in the server.xml file. This means that the servlet classes will be reloaded if the servlet has changed. This doesn't work for regular classes such as beans because they use a different class loader. (But Tomcat 4.0 is supposed to have something like this.) So just specify your servlets in web.xml and make sure reloadable="true" in the context in server.xml.

Class reload for split directory structure

I have tried to use the split directory structure in WL 8.1. I have a enterprise
application with 2 EJB modules and 2 WEB modules. I have tried to change one session
bean by just adding a logging statement and then use wlcompile to compile it.
Do I necessary call wldeploy to redeploy it? Or, will WebLogic automatically reload
the class file? Calling redeploy is so slow to me (about 3 minutes). Thus I want
to check if WL can just reload the class automatically.

Hudson Wong wrote:
I have tried to use the split directory structure in WL 8.1. I have a enterprise
application with 2 EJB modules and 2 WEB modules. I have tried to change one session
bean by just adding a logging statement and then use wlcompile to compile it.
Do I necessary call wldeploy to redeploy it? Yes
Or, will WebLogic automatically reload the class file? No, by default it load the EJB in the application classloader, and
everytning in the classloader must change for it to be visible.
Calling redeploy is so slow to me (about 3 minutes). Thus I want
to check if WL can just reload the class automatically.There is a bit of an advanced way in WLS 8.1 to get this to work.
In your weblogic-ejb-jar.xml, you need to set
<enable-bean-class-redeploy>True</enable-bean-class-redeploy>
This tells WLS to load the bean impl class in a sub classloader
then in weblogic.Deployer you have to specify the bean class that changed.
weblogic.Deployer -name myapp -redeploy myEJB/com/foo/MyEJB.class
That works as long as you only make changes to the bean class itself.
-- Rob

Class reloading

log4j.properties
log4j.category.com.bank=debug, M
log4j.appender.M=org.apache.log4j.RollingFileAppender
log4j.appender.M.File=log/ERR.log
i am reading this proerties file from java class.
only INFO messages will come in ERR.log file.
if i change this line like this log4j.category.com.eagle.profiling=error, M(only ERROR messages should come in ERR.log file)
without restarting the server can i change log4j.properties ?

Chaituu, whether you need to restart the server depends on where you put your log4j*.jar. Say, if it is at j2ee/home/applib, then the server needs to be started. If it is only packaged inside your application, then your need to restart/redeploy your application.
The basic idea here is that a running log4j system corresponds to the classloader that loads the log4j*.jar.

How to make servlets reloadable in iplanet web server in solaris??

hi all,
does anyone know how to make servlets reloadable in iplanet ??? Thanks for help

Hi there,
I think your question is about "Dynamic Class Reloading", also named as Hot deployment. and the following lines may be helpful.
iAS 6.0 SP3 and later version supports new hot deployment features through dynamic class
reloading of EJBs.By default, dynamic servlet, EJB and registered JSP reloading is disabled in iPlanet Application Server.
To enable dynamic reloading of servlets, EJBs and registered JSPs, perform the following steps:
1.Start iPlanet Registry Editor, kregedit, and modify the Disable value under the Versioning key:
SOFTWARE/iPlanet/Application Server/6.0/CCS0/SYSTEM_JAVA/Versioning
2.Set the Disable value to 0 (By default, the Disable value is set to 1)
3.Restart iPlanet Application Server to enable the change
To hot deploy your application, simply compile and replace the file in the appropriate directory or, use iasdeploy to redeploy
applications.
I recommand you to check out the iAS's release notes (http://docs.iplanet.com/docs/manuals/ias/60/sp3/rn_sp3.html#20766) for more infomation.
Good luck
Shen Jie
Developer Technical Support
Sun Microsystems
http://sun.com/developers/support

IPlanet 4.1 & class reloading

Similar Messages

Maybe you are looking for