|Yes, this is not j2ee-spec compliant and I agree, we should also support |standard packaging as well, this is just in addition, for those who see |advantage in having flexible packaging.
Yes that's the spirit, |> I think these are supplied in *service.xml via the classpath elements? | |Could very well be so, I have not looked into how *service.xml is |composed. yes but I think we should generalize this to the rest, so if we have a global xml file we can just specify the whole enchillada with a URL and classes and apps and modules can be downloaded from one central location. Of course spec compliant must still be there, but spec compliant packaging is a medieval aberation. |Now, even forgetting about subscoping, having an ability to add libraries |at module deploy time in the module descriptor is useful in and of itself. |Presumably, the deployment script or the person who deploys the app would |deploy truly global libraries into the global scope _prior_ to deployment |of any descriptors. And then each module at descriptor deploy time can |specify any additional libraries that go into the scope. This preserves |the locality of configuration -- if a library is really local, i.e. for |this module only, I should be able to specify where it is and how to |access it through the module descriptor, not in an unrelated scope |definition file. Same thing goes for WAR files, such as jsps, htmls, jpgs, |which are packaged into a jar. This jar is really 'local' to the WAR |module, so the information about this jar's location should be in WARs |deployment descriptor. I am not sure about this. The thing that bothers me is that wars are not a real unit of application and don't give me the reuse crap. Same goes for jars btw, ejbs aren't real units of standalone apps in most cases. What I am trying to say is that to keep metadata association in an arbitrary packaging format that only makes sense for distribution (files wars/jars) is silly and spec compliant but from a administration standpoint makes little sense. If you have a set of classes that belong to AN APPLICATION then just define that APPLICATION as a unit (run-time notion) FUCK THE WAY IT CAME PACKAGED. IT IS IRRELEVANT. What is important is "what application is running and what classes are needed". This we can easily do. At this point I think we are beating a dead horse, in the sense that in the purest tradition of this list we are running 2 milleniums ahead of ourselves with no implementation to discuss. So let's put something out before we babble more. |see more below aargh! |> It seems to me that this scheme would be a minor modification to my |> proposal to separate the "add stuff to scope classloader" and "process |> deployment descriptor" phases. As I understand what you are |suggesting it |> is that one should be able to deploy any deployment descriptor |> (jboss-service.xml, ejb-jar.xml, ra.xml, ....) by itself, into a scope, |> outside of its j2ee mandated packaging. | |Exactly, we should have an ability to configure classloading separately |from deployment of descriptors. And yes, it would be nice to be able to |deploy just a descriptor outside its packaging. yes |> How much overlap do you see between your suggestion of a all inclusive dd |> and my suggestion of a deployment script facility? |> |I am not familiar with the deployment script facility you have proposed, I |would be very interested in seeing it. And it seems to me it is a great |idea. Descriptors are not expressive or convenient enough in specifying |the sequence of commands and events that should happen during |deployment/undeployment/redeployment. A scripting facility is a great |idea. And just note that being able to glue xmls together would buy you an |ability to glue pieces of scripts into the descriptors as well. These |scripts would do the necessary scope configuration, event handling, |library registration, whatever. | Ok this is where the "scripting facility" of Jetty could be useful. I still have to see a clear case where it would be generic enough, but if this is the case then sure, I need to see it though. Are you guys familiar with the machine language of admin that Gregw came up with? It is totally un-admin friendly, but totally radical when it comes to expressing logic in scripts, (like create this object add this to that and then call this on the class etc etc), that is powerful but it is also a plague, We need it hidden behind graphical tools, not in your face XML. |> The only thing I am not completely comfortable with about this is how to |> specify the scope to deploy a j2ee dd into. Once it is deployed into a |> scope, perhaps by a deployment script or from a reference from some other |> jboss-specific dd, the autodeployer could do an undeploy/redeploy cycle |> since the "undeploy" operation could return the list of scopes the dd was |> deployed into, and redeploy the new version to all of them. The question of the cycle scope is an interesting one. It has to do with being able to determine the reachable classes at run-time. Right now David has build a simple sar-sar dependencies facility where you define the dependency. I built a automated way to track these and since we have lifecycle on the mbean we could totally automate that (i.e. the input to the facility would not be the dd dependencies but what comes from these smart classloaders). I think that Dr Jung implemented some of the ideas in his implementation and you can track the dependencies there (I don't remember clearly). Take a look. In short we can automate the tracing of calls. Of course it needs to be direct calls for our cl to intercept the first load operation. |In order to tie a descriptor to a scope one would either: | | wrap the descriptor within a super-jboss.xml which specifies | scoping of this descriptor | | or invoke the deployment of this dd into a scope (ala what | Dr. Jung's scoped deployer does now with archives). Yes, the SL needs to be extended to include scoped maps. That being said, I am fuzzy on why scoping is necessary, I suspect that running from the default visibility would be the way to do it, it would simplify our problems a lot. I think the scoping is necessary only when we want either security (can't see these classes) or versioning (load from this scope first then go default). It would need to be decided in the field. We are talking in a vaccuum right now (at least I am). |Let's say, I have an entity bean (CMP) I want to deploy. Currently I would |have to write 3 separate files ejb-jar.xml, jboss.xml and jaws.xml. Write |all the necessary classes, package this stuff together into a jar. In my |view of the system, the developer would glue all 3 xml files into one |file, say super-jboss.xml using namespaces, add an entry about |scoping and the classfiles JAR location. drop the descriptor into |scope. Or drop the jar with classfiles into scope and the simply deploy |the descriptor. | |What this would get me, is that, say, I want to add another finder |method. I just modify and redeploy the descriptor, no need to touch the |classes, repackage, etc. hmmmmmmm wrong example.... use ant, that is what we do today. I see an advantage is not having to deal with packaging location of classes at package creation (let's see do I need this class here or there? and what about this class does it need this interface? instead you would just attach the classes to a scope (default by default) and just run with the correct visibility built in. I am sorry I see little value in the proposal above. |In general it would appear to me that most developers don't want to keep |track of which classes will a particular bean need when deployed. Just YES that is the point but it un-correlated to the previous one! |build a library of all relevant project files. Write descriptors and let |JBoss take care of the rest. | |In my project, I am trying to deploy large applications piecewise on |multiple servers. Keeping track of which libraries which module needs is |just too cumbersome, it is much easier to just deploy descriptors for the |pieces I need on top of preconfigured CL scope that has all the classes |availble for module deployments. Ok the only thing needed here is the SL as parent of CL and WE ARE DONE! David it is really a 10 line change. |> david jencks |> |> (I'm not a dr, marc just thinks how I write is so convoluted I must be |> one;-) <flame> I know you are not a Dr, I can read it. I am real "dr", not that kind of "doctor" a real "Dr". As a "real Dr" I believe that the most difficult and noble task is to make complex knowledge appear simple, mass-communication of science and computer science is our goal here. I have no use for long mails with no code and little signal I can take out. It frankly impresses more when an idea, originally complex, has a simple solution, a simple implementation, and everyone goes "duh, of course!". When you achieve this you will recieve a real "Dr." title from me and it will mean something. Dr David Jencks, tons of abstract mathematics he has no real use for at Huuuvud, Doctorate in mass-communication from JBoss Group. We are a church, or rather we are building a church. I am an apostle, you are a priest that thinks that reciting mass in latin to our people is cool, cause the fat ladies in the front rows are impressed by your mastery, and you like the looks of it. You got it wrong! I don't want the religion to be out of reach! I want it to be mass-consummed, by every developer that wants it. It's got to be personal something they can relate to again something personal. I want people to read the code, one class a day, like others read the bible on weekends. Open book, Open knowledge, mass communication. I want you to spread the word dummy! I want you to serve the church, do not impress peasants with your knowledge of Latin, you will impress the fat ladies, not me my friend. The day you go through the hoops of making your communication of ideas simple I will be impressed. That day I promise I will give you the humble title of "Dr from JBG" and hopefully the revenues. I promise your brain will be in a new dimension, one of humility for the knowledge you know you own so intimately you can communicate it. You are a machine to massage and reformat knowledge, get brain with the program. Now go and make me proud. </peace> marcf |> > |> > |> > |------------------------------------------------------------------------- |> > Anatoly Akkerman |> > Computer Science Dept. |> > Courant Institute of Mathematical Sciences, NYU |> > 715 Broadway, #719 Tel: 212 998-3493 |> > New York, NY 10003 Fax: 212 995-4123 |> > |------------------------------------------------------------------------- |> > |> > |> > |> > _______________________________________________ |> > Jboss-development mailing list |> > [EMAIL PROTECTED] |> > https://lists.sourceforge.net/lists/listinfo/jboss-development |> > |> > |> > |> > |> > _______________________________________________ |> > Jboss-development mailing list |> > [EMAIL PROTECTED] |> > https://lists.sourceforge.net/lists/listinfo/jboss-development |> > |> > |> |> _______________________________________________ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | | |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
