6:17 p.m.
Since a number of users are complaining about us
trying to process WEB-INF/spring-beans.xml
as an MC -beans.xml file, even though
spring-beans.xml should be in WEB-INF/classes
I'm going to go through and change all our
-beans.xml files to end with -jboss-beans.xml
https://jira.jboss.org/jira/browse/JBAS-5803
e.g. ejb3-deployer-beans.xml becomes
ejb3-deployer-jboss-beans.xml
To try to keep the history of these files
I'll be moving them in the repository
along with seperate commits to the build files.
To try to keep the individual changes
as atomic as possible I'll be doing it project
by project in jboss-head.
Problems you might see:
1) I'll be doing the testsuite last, so
some of the overridden configs may not
work because it will be copying over the
wrong file until I've changed them.
2) If you are doing incremental builds
you might end up with both the old and
new file in your jboss image which
will surface as an attempt to deploy a bean twice.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
8:58 p.m.
I actually always wondered why we don't do a content check instead
of relying purely on filenames/suffixes ?
e.g. scan for -beans.xml but reject them if they don't match the first element or
proper dtd or something ?
Performance reasons ?
-max
Since a number of users are complaining about us
trying to process WEB-INF/spring-beans.xml
as an MC -beans.xml file, even though
spring-beans.xml should be in WEB-INF/classes
I'm going to go through and change all our
-beans.xml files to end with -jboss-beans.xml
https://jira.jboss.org/jira/browse/JBAS-5803
e.g. ejb3-deployer-beans.xml becomes
ejb3-deployer-jboss-beans.xml
To try to keep the history of these files
I'll be moving them in the repository
along with seperate commits to the build files.
To try to keep the individual changes
as atomic as possible I'll be doing it project
by project in jboss-head.
Problems you might see:
1) I'll be doing the testsuite last, so
some of the overridden configs may not
work because it will be copying over the
wrong file until I've changed them.
2) If you are doing incremental builds
you might end up with both the old and
new file in your jboss image which
will surface as an attempt to deploy a bean twice.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
9:38 p.m.
On Tue, 2008-07-29 at 13:58 +0200, Max Rydahl Andersen wrote:
I actually always wondered why we don't do a content check
instead
of relying purely on filenames/suffixes ?
e.g. scan for -beans.xml but reject them if they don't match the first element or
proper dtd or something ?
Performance reasons ?
Performance and its not very user friendly.
If the user mistypes the schema name then
we'd just ignore the file and the user
would have no idea what the problem is.
-max
> Since a number of users are complaining about us
> trying to process WEB-INF/spring-beans.xml
> as an MC -beans.xml file, even though
> spring-beans.xml should be in WEB-INF/classes
> I'm going to go through and change all our
> -beans.xml files to end with -jboss-beans.xml
>
> https://jira.jboss.org/jira/browse/JBAS-5803
>
> e.g. ejb3-deployer-beans.xml becomes
> ejb3-deployer-jboss-beans.xml
>
> To try to keep the history of these files
> I'll be moving them in the repository
> along with seperate commits to the build files.
>
> To try to keep the individual changes
> as atomic as possible I'll be doing it project
> by project in jboss-head.
>
> Problems you might see:
>
> 1) I'll be doing the testsuite last, so
> some of the overridden configs may not
> work because it will be copying over the
> wrong file until I've changed them.
>
> 2) If you are doing incremental builds
> you might end up with both the old and
> new file in your jboss image which
> will surface as an attempt to deploy a bean twice.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:37 p.m.
On 07/29/2008 04:17 AM, Adrian Brock wrote:
Since a number of users are complaining about us
trying to process WEB-INF/spring-beans.xml
as an MC -beans.xml file, even though
spring-beans.xml should be in WEB-INF/classes
I'm going to go through and change all our
-beans.xml files to end with -jboss-beans.xml
Does the file name matcher not use a longest-match kind of rule? If not,
perhaps it should... Intuitively this seems like the wrong move to me, but
I admit I'm not really sure why it seems that way.
- DML
9:40 p.m.
On Tue, 2008-07-29 at 07:37 -0500, David M. Lloyd wrote:
On 07/29/2008 04:17 AM, Adrian Brock wrote:
> Since a number of users are complaining about us
> trying to process WEB-INF/spring-beans.xml
> as an MC -beans.xml file, even though
> spring-beans.xml should be in WEB-INF/classes
> I'm going to go through and change all our
> -beans.xml files to end with -jboss-beans.xml
Does the file name matcher not use a longest-match kind of rule? If not,
perhaps it should... Intuitively this seems like the wrong move to me, but
I admit I'm not really sure why it seems that way.
The matching logic is in AbstractParsingDeployer.
Currently it is very simple - suffix matching, if you want to contribute
some more rules that's the place to do it.
- DML
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:22 p.m.
On 07/29/2008 07:40 AM, Adrian Brock wrote:
On Tue, 2008-07-29 at 07:37 -0500, David M. Lloyd wrote:
> On 07/29/2008 04:17 AM, Adrian Brock wrote:
>> Since a number of users are complaining about us
>> trying to process WEB-INF/spring-beans.xml
>> as an MC -beans.xml file, even though
>> spring-beans.xml should be in WEB-INF/classes
>> I'm going to go through and change all our
>> -beans.xml files to end with -jboss-beans.xml
> Does the file name matcher not use a longest-match kind of rule? If not,
> perhaps it should... Intuitively this seems like the wrong move to me, but
> I admit I'm not really sure why it seems that way.
The matching logic is in AbstractParsingDeployer.
Currently it is very simple - suffix matching, if you want to contribute
some more rules that's the place to do it.
AbstractParsingDeployerWithOutput is the "highest" class with a suffix
property on it. Searching for uses reveals that there really is no one
place where the matching logic is implemented.
AbstractVFSParsingDeployer's isDeployable(VirtualFile) method checks the
suffix and just returns a boolean, so presumably there's something that
scans through, looking for the first one that matches...
Looks like the logic is actually in FileStructure... though it doesn't work
how I expected. There's a checkFileMatchers() method that returns true if
*some* file matcher matches, though it doesn't say which one. Find usages
on that method reveals a dead end. I must be barking up the wrong tree?
Ah well, I'm defeated for now. Too much other stuff to do. If anyone else
wants to tackle this, I think it's worth doing, but beyond my capabilities
for the time being.
- DML
11:25 p.m.
On Fri, 2008-08-01 at 09:22 -0500, David M. Lloyd wrote:
On 07/29/2008 07:40 AM, Adrian Brock wrote:
AbstractParsingDeployerWithOutput is the "highest" class with a suffix
property on it. Searching for uses reveals that there really is no one
place where the matching logic is implemented.
That class provides the standard config options.
AbstractVFSParsingDeployer's isDeployable(VirtualFile) method
checks the
suffix and just returns a boolean, so presumably there's something that
scans through, looking for the first one that matches...
That class + its children implements the option(s),
since only the VFS provides the ability to "list a URL", e.g.
match all files in META-INF that end with the suffix.
Looks like the logic is actually in FileStructure... though it
doesn't work
how I expected. There's a checkFileMatchers() method that returns true if
*some* file matcher matches, though it doesn't say which one. Find usages
on that method reveals a dead end. I must be barking up the wrong tree?
Yep, its not even a tree you are barking at. :-)
The FileStructure is not doing parsing or META-INF searching.
It is looking for candidate subdeployments.
e.g. -service.xml files in the root of a jar.
We could just allow FileMatchers to be injected
into the parsing deployers (as Ales suggested to me).
That way somebody could change the matching rules to whatever they want.
But it smells to me like YAGNI. :-)
But configuring a FileMatcher for every parser
just to match a suffix or whole file name is overkill
for these simple use cases.
So if we were going to do it, the old simple rules should still be there
with the more complicated injectable FileMatcher resevered for
"power users".
Ah well, I'm defeated for now. Too much other stuff to do. If
anyone else
wants to tackle this, I think it's worth doing, but beyond my capabilities
for the time being.
- DML
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12:46 a.m.
On 08/01/2008 09:25 AM, Adrian Brock wrote:
We could just allow FileMatchers to be injected
into the parsing deployers (as Ales suggested to me).
That way somebody could change the matching rules to whatever they want.
But it smells to me like YAGNI. :-)
That seems kinda like overkill yeah; I think that the basic suffix rule is
just fine, just that the logic should be adjusted so that longer suffixes
are tried before shorter ones (that'd be a more obvious/predictable
behavior in my opinion). If I miraculously get some free time in the near
future I'll poke at it some more...
- DML
1:10 a.m.
On Fri, 2008-08-01 at 10:46 -0500, David M. Lloyd wrote:
On 08/01/2008 09:25 AM, Adrian Brock wrote:
> We could just allow FileMatchers to be injected
> into the parsing deployers (as Ales suggested to me).
> That way somebody could change the matching rules to whatever they want.
> But it smells to me like YAGNI. :-)
That seems kinda like overkill yeah; I think that the basic suffix rule is
just fine, just that the logic should be adjusted so that longer suffixes
are tried before shorter ones (that'd be a more obvious/predictable
behavior in my opinion). If I miraculously get some free time in the near
future I'll poke at it some more...
That isn't how it works. If two deployers match the file name
then they both process it. In this case it is irrelevant because
there is no jboss deployer that looks for spring-beans.xml
that is done by the Spring war context initializer.
The equivalent to what you want is anything that matches -beans.xml
but doesn't match spring-beans.xml
But again, even then it doesn't solve the problem since
they don't have to call it spring-beans.xml
That's why I changed the suffix to jboss-beans.xml
Of course it might still fail if somebody has configured there
context initializer to look for my-spring-jboss-beans.xml :-)
But like I said originally. WEB-INF/classes NOT WEB-INF
is the correct place for this file anyway, so we're
trying to solve a perceived problem because of bad
practice rather than a real bug.
- DML
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
2:44 a.m.
On 08/01/2008 11:10 AM, Adrian Brock wrote:
That isn't how it works. If two deployers match the file name
then they both process it. In this case it is irrelevant because
there is no jboss deployer that looks for spring-beans.xml
that is done by the Spring war context initializer.
Ahh, I see. Now the code suddenly makes more sense...
But like I said originally. WEB-INF/classes NOT WEB-INF
is the correct place for this file anyway, so we're
trying to solve a perceived problem because of bad
practice rather than a real bug.
That is probably the most important point of all.
- DML
9:58 p.m.
This should be done now.
I'll wait for the full testsuite run to see whether
there are any typos or missed changes.
On Tue, 2008-07-29 at 11:17 +0200, Adrian Brock wrote:
Since a number of users are complaining about us
trying to process WEB-INF/spring-beans.xml
as an MC -beans.xml file, even though
spring-beans.xml should be in WEB-INF/classes
I'm going to go through and change all our
-beans.xml files to end with -jboss-beans.xml
https://jira.jboss.org/jira/browse/JBAS-5803
e.g. ejb3-deployer-beans.xml becomes
ejb3-deployer-jboss-beans.xml
To try to keep the history of these files
I'll be moving them in the repository
along with seperate commits to the build files.
To try to keep the individual changes
as atomic as possible I'll be doing it project
by project in jboss-head.
Problems you might see:
1) I'll be doing the testsuite last, so
some of the overridden configs may not
work because it will be copying over the
wrong file until I've changed them.
2) If you are doing incremental builds
you might end up with both the old and
new file in your jboss image which
will surface as an attempt to deploy a bean twice.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5758
days inactive
5761
days old
jboss-development@lists.jboss.org
10 comments
3 participants
participants (3)
-
Adrian Brock -
David M. Lloyd -
Max Rydahl Andersen