Well marc, my goal here is to get a good system that works as well as
possible and is as simple as practical, not to piss you off. I apologize
for this inadvertent side effect. This is not the simplest thing I have
ever worked on, and I'm kind of thinking out loud.
One thing I feel really strongly about the new extensible classpath is that
it must be completely reversible to be of any real use: if deploying
something adds classes to the classpath, undeploying must be possible and
must remove them again. If this was easy, sun would have put it in java 1.
I don't think what we have now is working as well as it could be, and I
want it to be really easy to use without artificial constraints, as well as
totally reliable and as simple as possible.
On 2001.09.22 15:43:30 -0400 marc fleury wrote:
> |Well I would hope people would keep it simple and use
> |jar1
> |jar1
> |rar1
> |jar3
> |META-INF/jboss-service.xml
>
> where do you put the simple classes for the SAR (WHAT THIS IS SUPPOSED TO
> DO
> IN THE FIRST PLACE). The current stuff is
>
> dir1/dir2/class1
> META-INF/jboss-service.xml
>
> which is what the jar does for EJB as well
>
> simple... where is that structure? why requiring the jar?
This is no big deal... my thinking is that sun calls packages that directly
contain classes (+ deployment info) jar, whereas anything that is called
xar requires unpacking before use to get to the internal packages. Since
we're calling these sar, I thought it might make sense to require the
classes to be in an internal jar, like rar format. I do want to be able to
put a jar into a sar rather than having to unpack the classes from the jar
and repack them into the sar... it is so easy to jar up the classes and
then package the jar/w the deployment info I thought one format agreeing
with suns usage might be enough. Either way is cool.
>
> |> Also explain how that includes the "directory" requirement from say
> |> JBossMQ
> |> that david was asking for.
> |
> |I'm not convinced by this one yet as I understood his proposal, so I
> |haven't started trying to implement it. I don't think the temp
> deployment
> |directory should be used for the app to write to-- too much like self
> |modifying code. Also I think administrators would want to be able to
> |control space usage - especially if you are storing something like a db
> |there. How about an mbean that sets up a temporary/permanent directory
> for
> |you, and interacts with jboss spine in some way to negotiate about
> where?
> |(for instance, now, in the db directory)
>
> fascinating...
>
> Are you thinking with your head backwards?
>
> The ONLY FEATURE THAT HAS BEEN REQUESTED BY JASON (unix admin pellets),
> DAVID (MQ dir), JULIAN( JETTY dir) IS THE ONLY FEATURE YOU ARE "not
> convinced"... wow...
>
> You keep spouting obscure, non-obvious features, that you pull out of
> your
> arse, but on the only CLEAR FEATURE (the directory layout) you say "not
> convinced"...
>
> I am tired of Open Source discussions.
I didn't mean the directory thingy was a bad idea, but I haven't figured
out how to implement it yet, and I can only do so much at once. Its less
than obvious to me how to make this directory idea work. Does each
deployed package needs its own directory namespace, or should we let
packages break each other if they happen to specify the same directory
tree? If we let them break each other, this is pretty easy. If we don't,
there's a lot of bookkeeping, that I think belongs in an mbean.
I don't remember what jason wanted with unix admin pellets, can someone
remind me?
Thanks
david jencks
>
> |> Go ahead,
> |> marcf
> |
> |Thanks
> |david jencks
>
> I maintain the go-ahead. If the features are not there someone else will
> try to do them, if the features there are not relevant it won't be
> used...
> sue me.
>
> You scratch your itch...
>
> marcf
>
> |>
> |> |Thanks
> |> |david jencks
> |> |
> |> |_______________________________________________
> |> |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
