9:19 a.m.
I just noticed that we redeploy an entire application if a xml file gets
added/removed from the metadata locations of a application. For example,
if in an exploded WAR file we add a somefile.xml to the WEB-INF folder
the application gets redeployed (easily reproducible in ROOT.war). Why
do we do this? I thought redeploy would be triggered by touching the
deployment descriptor of the app (i.e. changing the last modified time
of web.xml). Looks to be intentional from what i see in the
configurations (profile.xml):
<!-- This just checks metadata locations -->
<bean name="MetaDataStructureModificationChecker"
class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker">
<constructor>
<parameter><inject bean="MainDeployer" /></parameter>
</constructor>
<property name="cache"><inject bean="StructureModCache"
/></property>
<property name="filter"><bean
class="org.jboss.system.server.profile.basic.XmlIncludeVirtualFileFilter"
/></property>
</bean>
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasStructureBeenModifed(...):
// do we have some new files or some were deleted
if (leaves != null && children != null &&
leaves.size() != children.size())
{
if (log.isTraceEnabled())
log.trace("Metadata files number changed, old: "
+ leaves + ", now: " + children);
return true;
}
Why do we have to redeploy the application if a xml is added to the
metadata folder of a application?
-Jaikiran
8:36 p.m.
This is just a configuration detail -- up to the filter to determine
possible files.
In this case it's the all .xml files.
Since at least I would expect the AS to pick up my new .xml config file.
Or why would you put it there?
Jaikiran Pai wrote:
I just noticed that we redeploy an entire application if a xml file
gets
added/removed from the metadata locations of a application. For example,
if in an exploded WAR file we add a somefile.xml to the WEB-INF folder
the application gets redeployed (easily reproducible in ROOT.war). Why
do we do this? I thought redeploy would be triggered by touching the
deployment descriptor of the app (i.e. changing the last modified time
of web.xml). Looks to be intentional from what i see in the
configurations (profile.xml):
<!-- This just checks metadata locations -->
<bean name="MetaDataStructureModificationChecker"
class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker">
<constructor>
<parameter><inject bean="MainDeployer" /></parameter>
</constructor>
<property name="cache"><inject bean="StructureModCache"
/></property>
<property name="filter"><bean
class="org.jboss.system.server.profile.basic.XmlIncludeVirtualFileFilter"
/></property>
</bean>
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasStructureBeenModifed(...):
// do we have some new files or some were deleted
if (leaves != null && children != null && leaves.size()
!= children.size())
{
if (log.isTraceEnabled())
log.trace("Metadata files number changed, old: "
+ leaves + ", now: " + children);
return true;
}
Why do we have to redeploy the application if a xml is added to the
metadata folder of a application?
-Jaikiran
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
8:44 a.m.
Ales Justin wrote:
Since at least I would expect the AS to pick up my new .xml config
file.
Or why would you put it there?
That does not require a redeploy of the entire
application. The user can
place the xml there and be able to look it up without having to redeploy
the application. Am i missing something?
-Jaikiran
Jaikiran Pai wrote:
> I just noticed that we redeploy an entire application if a xml file
> gets added/removed from the metadata locations of a application. For
> example, if in an exploded WAR file we add a somefile.xml to the
> WEB-INF folder the application gets redeployed (easily reproducible
> in ROOT.war). Why do we do this? I thought redeploy would be
> triggered by touching the deployment descriptor of the app (i.e.
> changing the last modified time of web.xml). Looks to be intentional
> from what i see in the configurations (profile.xml):
>
> <!-- This just checks metadata locations -->
> <bean name="MetaDataStructureModificationChecker"
>
class="org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker">
>
> <constructor>
> <parameter><inject bean="MainDeployer"
/></parameter>
> </constructor>
> <property name="cache"><inject
bean="StructureModCache" /></property>
> <property name="filter"><bean
> class="org.jboss.system.server.profile.basic.XmlIncludeVirtualFileFilter"
> /></property>
> </bean>
>
>
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasStructureBeenModifed(...):
>
>
> // do we have some new files or some were deleted
> if (leaves != null && children != null &&
> leaves.size() != children.size())
> {
> if (log.isTraceEnabled())
> log.trace("Metadata files number changed, old:
> " + leaves + ", now: " + children);
> return true;
> }
>
> Why do we have to redeploy the application if a xml is added to the
> metadata folder of a application?
>
> -Jaikiran
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
7:17 p.m.
Ales Justin wrote:
> Since at least I would expect the AS to pick up my new .xml config file.
> Or why would you put it there?
That does not require a redeploy of the entire application. The user can
place the xml there and be able to look it up without having to redeploy
the application. Am i missing something?
Sure, but how do I know if he really didn't mean to add new config file?
e.g. new custom config file where he describes his new services, wanting
to propagate some service all the way to the business logic code
8:54 a.m.
Ales Justin wrote:
> Ales Justin wrote:
>> Since at least I would expect the AS to pick up my new .xml config
>> file.
>> Or why would you put it there?
> That does not require a redeploy of the entire application. The user
> can place the xml there and be able to look it up without having to
> redeploy the application. Am i missing something?
Sure, but how do I know if he really didn't mean to add new config file?
e.g. new custom config file where he describes his new services,
wanting to propagate some service all the way to the business logic code
In that
case, he would be expected to touch the top level deployment
descriptor (web.xml in this case) to tell us (the AS) that the
application needs to be redeployed. That's how AS-4.x handled this -
allowing the user to decide when the app needs a redeploy.
But i guess, this isn't a major change as long as we let users know that
this is how AS-5 is expected to behave :)
-Jaikiran
12:42 p.m.
It does look like a good idea to introduce changes in behavior, unless users have asked
for it.
Jaikiran Pai wrote:
Ales Justin wrote:
>> Ales Justin wrote:
>>> Since at least I would expect the AS to pick up my new .xml config
>>> file.
>>> Or why would you put it there?
>> That does not require a redeploy of the entire application. The user
>> can place the xml there and be able to look it up without having to
>> redeploy the application. Am i missing something?
>
> Sure, but how do I know if he really didn't mean to add new config file?
> e.g. new custom config file where he describes his new services,
> wanting to propagate some service all the way to the business logic code
In that case, he would be expected to touch the top level deployment
descriptor (web.xml in this case) to tell us (the AS) that the
application needs to be redeployed. That's how AS-4.x handled this -
allowing the user to decide when the app needs a redeploy.
But i guess, this isn't a major change as long as we let users know that
this is how AS-5 is expected to behave :)
-Jaikiran
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:54 p.m.
It does look like a good idea to introduce changes in behavior,
unless
users have asked for it.
Are you missing a *not* there ? :)
btw. JBoss Tools relies on being able to restart applications by
touching the relevant descriptor, so please let us know if that changes :)
Another note is that it would actually be *better* if users could just
touch the root directory of the deployment so there is a *uniform*
way of "restarting" an application instead of having to know which
specific deployment descriptor to touch...would that be doable ?
(of course need to test that certain os's doesn't change the timestamp
of a directory just because you change a file below to avoid
triggering restart just because I updated index.html)
/max
Jaikiran Pai wrote:
> Ales Justin wrote:
>>> Ales Justin wrote:
>>>> Since at least I would expect the AS to pick up my new .xml config
>>>> file.
>>>> Or why would you put it there?
>>> That does not require a redeploy of the entire application. The
>>> user can place the xml there and be able to look it up without
>>> having to redeploy the application. Am i missing something?
>>
>> Sure, but how do I know if he really didn't mean to add new config
>> file?
>> e.g. new custom config file where he describes his new services,
>> wanting to propagate some service all the way to the business logic
>> code
> In that case, he would be expected to touch the top level deployment
> descriptor (web.xml in this case) to tell us (the AS) that the
> application needs to be redeployed. That's how AS-4.x handled this -
> allowing the user to decide when the app needs a redeploy.
>
> But i guess, this isn't a major change as long as we let users know
> that this is how AS-5 is expected to behave :)
>
> -Jaikiran
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:37 a.m.
> It does look like a good idea to introduce changes in behavior,
unless
> users have asked for it.
Are you missing a *not* there ? :)
I guess previous behavior was by design - monitoring just 'known' config
files.
e.g. WARDeployer --> web.xml, jboss-web.xml
As it was WARDeployer that did it _all_ for .war deployment.
But with new aspectized deployers, this approach cannot work.
As you actually don't know which all config files are valid in some
metadata location.
e.g. WEB-INF/my-custom.foo is completely valid if I have a *.foo
matching deployer
It is now responsibility of the StructureModificationChecker to
recognize changes.
It mostly boils down to SMC's filter to know which files to monitor.
One solution would be to have a filter which would do incallback on
FileMatcher,
which is what all sub-AbstractVFSParsingDeployer deployers implement.
This would probably catch most of the config use cases.
e.g. you could easily by-pass it by not extending
AbstractVFSParsingDeployer or not implementing FileMatcher on your
custom deployer
10:17 a.m.
But with new aspectized deployers, this approach cannot work.
As you actually don't know which all config files are valid in some
metadata location.
e.g. WEB-INF/my-custom.foo is completely valid if I have a *.foo
matching deployer
Then wouldn't looking into just redeploy on root dir touch to
make this
simpler for users ?
Or does the touch of descriptors allow for partial deployment, if yes
are they useful ?
/max
It is now responsibility of the StructureModificationChecker to
recognize changes.
It mostly boils down to SMC's filter to know which files to monitor.
One solution would be to have a filter which would do incallback on
FileMatcher,
which is what all sub-AbstractVFSParsingDeployer deployers implement.
This would probably catch most of the config use cases.
e.g. you could easily by-pass it by not extending
AbstractVFSParsingDeployer or not implementing FileMatcher on your
custom deployer
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5445
days inactive
5448
days old
jboss-development@lists.jboss.org
8 comments
4 participants
participants (4)
-
Ales Justin -
Dimitris Andreadis -
Jaikiran Pai -
Max Rydahl Andersen