Hi All,
here are some thoughts from my old IT Spec perspective :)
Maybe I'm smoking something but wouldn't it be easier for the end user if we just offer them a
simpler directory structure for the applications !?!?!?
- This structure would be beneficial from a production stand point
<system_apps>/
here we put all the product applications. Very little end user updates here, maybe some
customization at the initial build time if they are customizing Geronimo. We could keep all the apps
JARed in this structure.
<user_apps>/
here we put all the user applications deployed via the deployer tool or the console. Here is where
we have the bigger problem if the users use the same philosophy as we do with maven. I think here is
where we need to focus.
<hot_deploy>/
this is within the <user_apps> dir. It will not be used too often in production, eitherway, most of
the apps deployed here will be packaged as a jar or ear so we should not see any problems with the
naming here.
- The same structure from a development/customization stand point
<system_apps>/
lots of updates from the end user. It might still be more convenient to maintain a short naming
convention for easier browseability (hmmm, does that word actually exists!?). What is the problem
using back the jars? repackaging? can we provide a tool (script, classloader!?) for updating the jar
automatically?
<user_apps>/
not much end user interaction, most of the testing may be performed via hot
deployment.
<hot_deploy>/
same as before, most of the apps deployed here will be packaged as a jar or ear so we should not see
any problems with the naming here.
Cheers!
Hernan
David Jencks wrote:
I've thought about not unpacking car files but rather flattening
everything in them and writing a classloader that can deal with offsets
within a jar file. This would completely solve the problem except for
peoples desire to fiddle with jsp files on the fly.
For this, maybe we should allow a car file has the config.ser (in xml
:-) as now but the rest of it is a map to the actual locations of the
files? I think it might be possible to include this in either a second
"development-friendly" config store (in a special location) or the
standard config store.
thanks
david jencks
On Apr 7, 2006, at 10:29 AM, Dain Sundstrom wrote:
Please stop blaming the m2 repo structure for this problem. The m2
repo structure only increased the path of our longest path by 36
characters. The true problem is that David and I moved the unpacked
configurations into the repository. We did this because of the
chunkiness of the numbered directories in the config-store
directory. The m2 repository structure makes querying the repository
for version numbers possible and it is this querying that makes
optional version numbers possible.
I think we have two issues that both must be addressed:
1) The ears we generate in our build have very long internal paths,
154 characters. This is just bad form, and vastly reduces the user
path head room.
2) We need to move the unpacked ears our of the repository and into a
separate flat directory structure.
I can look at the second one later today after fixing the redeploy
command. Can someone take a look at getting our build to jar up the
classes and compiled jsps in our build. I'll fix the generated
classes in our build.
-dain
On Apr 7, 2006, at 6:50 AM, 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.