Hi All,
I agree with Matt, we need to find a common ground, something in between the very short, number
based structure (and BTW not too meaningful) we had in the config-store and the "unnecessary" long
directory structure and file names that we are having now.
Independently of the Windows limitation for handling long names, I personally think that having a
structure as long (that potentially will keep growing) is unnecessary. What is the benefit of such a
'very' verbose naming? Sooner or later is going to become unpractical to browse through such a
complex structure no matter what OS you are using.
Matt's alternative going back to the config-store sounds good (I would also suggest to limit the
configId to a max number of chars) but we will still be facing the application naming area (222...).
This is the are we have less control and, IMHO, where we should focus on.
Cheers!
Hernan
Matt Hogstrom wrote:
Thinking about this some more I believe we need to make a good decision
here as having to revisit this issue in the future will cause users to
have to change how the server works. I've been talking to a new user
that has a larger server farm and is very interested in the Geronimo
server as their new foundation. However, they run a few thousand
servers and are VERY sensitive to changes in the behaviour of the server
in terms of how it impacts them. Changes to the repsoistory will affect
their operational experience dramatically and they do run Windows (go
Bill Gates). They are watching this thread with keen interest. Their
biggest concern is changing how their build and distribution system
works and changes in this area is highly disruptive for them.
My view of the problem is that there are really three distinct areas of
a path. They are the user area, the server area and the application
area. Let me splain...
| 0000000000000000000000000000 |
11111111111111111111111111111111111111111 | 2222222222222222222 ...
C:\my\directory\before\geronimo\geronimo-1.1\repository\com.apache.geronimo\console-1.1\appArtifacts
The area in the 0's are controlled by the user and we need to leave more
headroom than a few characters so they can manage multiple deployments
of Geronimo; this could include multiple versions or multiple
deployments. The users probably enjoy flexibility in naming as much as
we do. We don't have control over this but we influence how much
headroom is available.
The 1's is really the area we have control over as this is the server
proper. This includes the area from the top of the tree to the end of
where the files we create end. So, for instance, this includes var,
repository, etc. Since were currently experiencing this problem in the
respository I think we should focus on this area.
Finally, the 2's are the area that include the application and Maven
dependent information. The Maven naming convention is verbose. The
current implementation needs to be changed, the question is how and can
the change survive several releases so that our users are not forced to
change their deployments on each subsequent release. *One immediate
thought I had was to place applications back into the config-store (or
equivalent name). Rather than simply use a number as we did previously
perhaps the configId of the deployment would be appropriate. Its human
readable and would be shorter than the current maven structure.* I
highlighted the previous as I think this is the best option based on
what I know today.
Perhaps there some way to provide a Maven abstraction that would map
Maven dir names to an internal format for us. I expect if we are
running into this its only a matter of time befoew other Maven users
experience the same issues. For us its the nesting of Maven articacts /
configurations that is causing us the problem. Jason, thoughts?
Whatever we decide we need to ensure that it is stable enough to work
for a period of time.
Matt
Dain Sundstrom wrote:
Man I hate Windows....
Anyway, if you have a real OS and list the files in an assembly, you
will see that the problem is caused by the combination of two
changes: we now keep configurations in the repository and we unpack
them. If you look closer you will see that the big offenders are
unpacked ears and wars.
I believe the following are the longest paths in the server:
(270)
geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty/1.1-
SNAPSHOT/daytrader-derby-jetty-1.1-SNAPSHOT.car/daytrader-web-1.1-
SNAPSHOT.war/META-INF/geronimo-generated/org/apache/geronimo/axis/
client/GenericServiceEndpointWrapper$$EnhancerByCGLIB$$36344d29.class
(264)
geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1-
SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console-
standard-1.1-SNAPSHOT.war/WEB-INF/classes/org/apache/geronimo/console/
databasemanager/wizard/DatabasePoolPortlet$ResourceAdapterParams.class
One thing to note here is that the longest paths are all classes
generated by Geronimo, nested classes in wars or compiled JSP pages.
Someone should look into makeing maven jar the latter two and
Geronimo should be creating jars when generating classes (actually we
should stop generating classes a head of time but that is another
story).
Breaking down the longest path, we have:
GeronimoName (22)
geronimo-1.1-SNAPSHOT
RepositoryPath (55)
repository/geronimo/daytrader-derby-jetty/1.1-SNAPSHOT
FileName (39)
daytrader-derby-jetty-1.1-SNAPSHOT.car
NestedPath (154)
daytrader-web-1.1-SNAPSHOT.war/META-INF/geronimo-generated/org/
apache/geronimo/axis/client/GenericServiceEndpointWrapper$
$EnhancerByCGLIB$$36344d29.class
The first thing to note is if we simply replace "SNAPSHOT" with "0",
we drop 28 characters which makes the longest path 242; not enough
head room. Of course, when we switch our groupId to the maven
standard org.apache.geronimo we eat up 20 more characters. If we are
going to unpack war files there is very little we can do about the
NestedPath, so we have very few choices left. If we simply combine
combine ${GeronimoName}/${FileName}/${NestedPath} we are up to 115
characters leaving only 41 characters for anything else, but when you
add back the 28 from "SNAPSHOT", you get to a more comfortable level.
I think if we combine this problem with Sachin's request for a
separate directory for applications, we could do something like this:
${GeronimoName}/apps/${FileName}/${NestedPath}
There are several problems with this. I think users will confuse the
hot-deploy directory "deploy" with the "apps" directory [1]. Then
again, if you look at the problem configurations they are all apps
the users may want to remove (sample apps and the console), so may be
we should just put these in the hot-deploy directory. Another
problem is that it will be much more difficult to query a repository
without a directory structure. The server will basically have to
read the configuration from these apps on startup to determine what
they are, so again we may just want to use the hot-deploy directory.
I'm not a fan of the hot-deploy directory, but I'm not sure there is
a better solution.
Again I renew my hate of Windows...
/me shakes his fist at Bill Gates
-dain
[1] As a side issue, I prefer the name "apps" because it will be most
familiar to tomcat users.
